How do instructions from a program get sent to different memory levels? Are they pre-loaded when the chips are manufactured for the first time?

Question

I had asked a question earlier on how data gets pushed to registers in the CPU

My question now is, do instructions required for program execution get moved to memory by the compiler the same way data gets pushed?

If the answer to the first question is yes, then what do CPU designers load into the cache/main memory when it comes fresh out of the foundry? Since no program has ever been run before on the chip, are any instructions preloaded into memory at the time of designing and manufacturing of the chip so that it executes a pre-defined set of sequences when it is powered up for the first time?

Answer 1

How do instructions from a program get sent to different memory levels?

The processor pulls them into caches using the program counter aka instruction pointer that refers to the next instruction to execute.

Are they pre-loaded when the chips are manufactured for the first time?

Not for general purpose programs.  Only special environments burn programs into permanent storage, like ROM, which may happen for booting a computer or for an embedded system.  General purpose programs rely on an operating system to associate their code & data with memory.

My question now is, do instructions required for program execution get moved to memory by the compiler the same way data gets pushed?

Recap: The compiler follows the statements & expressions of the (source) code program, translating them into machine code instructions & data; these machine code instructions instruct the processor what to do to carry out the high level language program.  This includes machine code instructions to load data into CPU registers, sometimes so that the data is closer to the CPU so quicker to work with, other times because that is the only way that the CPU can operate on the data (by the machine code instruction set of the processor).

There is a difference between having machine code instructions in memory and having them in the processor.

The compiler does not, per se, command instructions to be moved into the processor.  The processor is an interpreter of machine code instructions, and all on its own it will pull instructions into itself for execution.  The compiler lays out sequences of instructions and the CPU automatically brings them in for execution — that is is the CPU's purpose.

Program code _{(modulo modern caches)} is too large to directly load into the CPU.  Thus, programs are stored in main memory, like data that is too large to fit directly in the CPU.  Program code is sequences of machine code instructions.  Since these instructions are stored in memory, each individual instruction has a unique memory address!  The processor refers to instructions by their memory address, and by their memory address has a concept of what instruction is executing now and what will/should execute next.

The mechanism for this goes to the instruction pointer register (in intel-speak) or the program counter register (in virtually all other machine code languages), but the concept is the same: there is a fundamental register inside the processor whose job is to hold the address of machine code instruction that is executing now, and whose job is also to change to indicate what instruction to execute next.

As mentioned, the processor is an interpreter of machine code instructions.  It uses its internal program counter in what is called a fetch-execute pattern, where it demands of the memory system the value of the machine code instruction to execute next.  That demand, a request to read an some particular memory address, may cause cache misses, or page fault (or both), which ultimately, through conspiracy of both the processor and the operating system, will cause machine code instructions to load into memory, to load in to caches, to load into the processor itself.

Each machine code instruction of the program informs the processor what machine code instruction to execute next.  The program can move the program counter backwards to re-execute instructions that have already executed (forming loops) or move it forward to exit a loop or skip a then or else statement.  There is a cooperation between the processor and the machine code, where the processor is told, at every step, what machine code to execute next.  So, the machine code program is directing the execution of sequences of the machine code program, but it is the processor that is doing the actual execution (though under the direction of the program).

Would we say that the compiler tells the processor to load instruction to execute into the CPU?  Sort of, but not quite as explicitly as commands to load data into the CPU.

The compiler creates a sequences in the machine code program used to control execution, so I would say it implicitly tells the processor what instructions to bring into the caches.  Otherwise (modulo memory mapping and page faulting) the machine code instructions are already in memory (by the operating system associating the memory with the program code & data), and the processor will manage caches to keep frequently executing instructions in the higher levels of the cache.

what do CPU designers load into the cache/main memory when it comes fresh out of the foundry?

Nothing, the memory is considered blank and can be repurposed.  On some systems we cannot even guarantee the value of each memory cell when the processor boots.  Where the program (as a file on disc) specifies the proper initial values for memory, then the original values that were in memory, from boot or from another program's execution, are replaced with those specified values.  Other memory used by the program is zeroed out before use.

are any instructions preloaded into memory at the time of designing and manufacturing of the chip so that it executes a pre-defined set of sequences when it is powered up for the first time?

Yes, sometime some memories are hard-coded with code and data that helps the computer boot.  This is not a general purpose way that programs run.

Answer 2

I think you are trying to over-complicate this. Your question is of course quite broad and there are different solutions.

Microcontrollers, MCUs, tend to have some form of non volatile storage, today that means flash. For each brand/family/product there is some way to program that flash using the pins of the part in some way. The machine code, the program/instructions as well as data can be programmed into this flash. Then on a normal boot, the processor in the mcu will start executing those instructions and run the application.

Normal processors, or let's say non-mcus, typically do not have on chip non-volatile storage. There will normally be some form of off chip non-volatile storage be it a flash, an SD card interface, etc. This storage will contain the machine code, etc, that boots the chip and gets it going.

Some processors have on chip sram and have some interface that one may be able to come in through an interface on the chip to halt the processor, load that memory with instructions and start execution of those instructions. Some may use this sram in a way that logic on reset/boot will copy instructions from an sd card to this sram, then start the processor executing from that sram.

There is no one way that every processor boots.

Once running an operating system for example, a program from a hard disk can be loaded into ram by the operating system, and then a jump to that code starts it running.

cache is just cache, it is in between the processor and the main memory (usually dram for Linux/Windows/MacOS type systems). You generally have an MMU, memory management unit, that is configured by software (kernel/operating system) to describe the system and define which parts of the address space are to be cached and in what way (instruction, data, etc). Then when memory transactions happen from the processor, and go through the mmu, that will mark the transaction as cacheable or not, then the cache, if configured and enabled, will....cache that transaction...You do not fill the cache directly, the cache is basically automatic and based on transactions going by, generally not predictable.

There have been processor chip designs, that for various reasons, have an on chip rom or flash, that is programmed by the chip manufacturer. This can be used to drive microcode for a CISC design, this can be a factory bootloader for an MCU, or other reasons.

Memory, DRAM, is dynamic D, not only do you have to work for it to retain any information, it is volatile, when the power goes off, or refreshes stop, it loses its information. You definitely do not preprogram this at some factory.

Same goes for SRAM.

Except for some very rare cases, the logic is designed such that it boots off of some non-volatile storage (these days that is some form of flash device on chip or off). That non-volatile storage is generally programmed by the PRODUCT vendor (not chip vendor), computer motherboard, TV set top box, cell phone, etc. That code generally then looks for additional software possibly on another non-volatile storage of some sort (hard disk, SSD, etc). And then of course that software may be an operating system, that can then run other various applications (web browser, mail program, games, etc). You often have one solution to get the chip booted, dram initialized, etc, to prepare the system to load and run an operating system off of some media, not uncommon to be different from the boot loader. Then the operating system loads and runs applications, usually from the same media that held the operating system.

The car is generic. The user has to insert a key and turn it on and start it. Then the user has to drive it somewhere. Multiple steps for the thing to do its job. The design for the car is such that the driver is not pre-built into the car, but instead a generic interface such that countless different operators can start and drive the car.

Same with a processor/system, reset starts the bootloader, the bootloader loads the operating system, the operating system loads the applications. The software is stored in one or more forms of non volatile storage and loaded through generic interfaces designed into the hardware (chip or board).

RAM, including layers of caches, are simply volatile storage devices on layers of buses according to some design. Professor writes formulas on the whiteboard, from their brain, student copies those formulas onto paper, longer term storage. Professor runs out of white board and starts to erase some of the info to make room for more. The whiteboard is just a cache between the professor and the students notebook. There is no reason for the whiteboard to be pre-loaded with a fraction of one lecture when the building is constructed. It is designed to be used and reused runtime.