I have read in my subject "Operating Systems" that CPU can't access secondary memory. Any program that is stored on secondary memory is executed once its retrieved from secondary memory to primary memory. Is this true? If the CPU can't execute code directly out of secondary memory, why not?
closed as unclear what you're asking by user340082710, vonbrand, Luke Mathieson, Evil, Juho Oct 28 '15 at 14:47
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
There are CPUs that can execute programs directly from secondary memory. (I'm kind of surprised at you not being able to simply search this: e.g.http://www.analog.com/media/en/technical-documentation/application-notes/EE363v01.pdf)
That being said, many CPUs cannot. It generally boils down to access speeds and/or I/O type. Secondary storage (flash, etc) can be slower and/or have more latency than RAM, and for a simple CPU (i.e. embedded system or similar, generally) the CPU may not be able to wait the length of time necessary to do an instruction fetch. (Or rather, it may assume that an instruction fetch will complete in cycles as opposed to having a mechanism to wait until the instruction is actually fetched)
Also, unless you have memory-mapped I/O or a proper MMU you'll need explicit support by the CPU to issue the I/O instructions required, which increases the complexity of the CPU and may increase the critical path, limiting the speed of the CPU. (If you have a MMU you can just have a page fault handler that fetches the appropriate page from secondary memory on first access)
Ultimately, a CPU has to be able to read the data for its next instruction. This is generally only a few bytes at most. However, many devices only support block-level access (e.g. 512 bytes, etc) of larger block sizes than the instruction size. Note that this includes many forms of RAM! (For instance, if you have DDR ram (64 bits transferred at a time) and an instruction set that isn't always 64 bits wide) There are a couple of ways to deal with this mismatch: you can fetch the block and toss away the data you don't need for that instruction, you can fetch the block into a small sliding window of the next few instructions (throwing away the rest of the block) so you only need to do a fetch every few instructions, or you can fetch the entire block into a buffer. Fetching every instruction is slow, and in particular is latency-sensitive. It also wastes memory bandwidth that could be otherwise used for DMA, for instance. Fetching into a sliding window can faster, but substantially more complex. It also introduces latency variations (if you have unpredictable branches you may not be able to keep the window filled, for instance) And fetching the entire thing limits you and requires a lot of die space for the buffer (you need to have a buffer at least as large as the block size), and is prone to problems (e.g. what happens when an instruction overlaps two blocks? There are a lot of edge cases.)
The CPU reads directly from primary memory (RAM). To read data from secondary memory (primarily disk), it is first read into primary memory.
Secondary memory is organized into blocks, and data is transferred from/to primary memory a block at a time. Thus to do the above, space must be allocated first, and then the correct commands given to the specific device (devices do differ in the exact incantations required to have them do the specified dance) to transfer data. This is too complex (and too time consuming) to have it done transparently by the CPU.