Flash and RAM : Code Execution

Question

I recently started learning assembly and came to know about linker scripts and other low-level details of hardware programming. I am also teaching myself computer architecture and somewhere along the line I came to fear that my picture of the memory model might have been wrong all along.

According to what I understand currently, all the code and data resides on the non-volatile memory just after we 'burn' the binary onto a processor - the RAM being volatile contains nothing upon reset. When the program begins 'executing' it does so from the address 0x0000 which is almost always (AFAIK) the lowest address in Flash. So, instructions are latched onto the bus connecting Flash to the CPU core and that is where the actual execution takes place. However, when we talk about the CPU retrieving or storing data from the memory, we're usually talking about RAM - I am aware that we can read/write data from the program memory as well (I've seen this done on AVRs) but is it not as common? Is it because RAM is faster than ROM that we prefer to store data there?

The accepted answer to this question says that most pieces of code execute out of RAM.

Does this mean that the start-up runtime code (which itself executes from Flash) has to copy all the program opcodes from Flash to RAM and somehow maps the addresses in Flash to point to RAM so that the CPU fetches opcodes from there? Is it similar to the process in which we move the .data sections from ROM to RAM on startup?

I can imagine this to be simpler in von Neumann architectures where the program and data memories share a bus but in Harvard architectures wouldn't this mean that all the code and data have to pass through the CPU registers first?

As you can probably guess, I am a little too confused by this whole business. Having always programmed at a higher abstraction level I am easily troubled with such details. Any help is appreciated.

Answer 1

This depends on the device.

RAM can be built faster than Flash; this starts to become important in about the 100MHz range.

Simple microcontrollers

Small slow microcontrollers execute directly out of Flash. These systems usually have more Flash than SRAM too.

Midrange systems

Once your device gets faster then the situation is a little different. Midrange ARM systems may do that as well, or they may have a mask ROM bootloader that does something smarter: perhaps downloading code from USB or external EEPROMs into internal SRAM.

Large systems

Larger, faster systems will have external DRAM and external Flash. This is typical of a mobile phone architecture. At this point, there is plenty of RAM available and it's faster than the Flash, so the bootloader will copy and execute it. This may involve shovelling it through the CPU registers or it may involve a DMA transfer if a DMA unit is available.

Harvard architectures are typically small so don't bother with the copying phase. I've seen an ARM with "hybrid harvard", which is a single address space containing various memories but two different fetch units. Code and data can be fetched in parallel, as long as they are not from the same memory. So you could fetch code from Flash and data from SRAM, or code from SRAM and data from DRAM etc.

Answer 2

RAM is generally faster than flash, but it doesn't really matter until you're hitting clock speeds in excess of 80-100MHz or so - as long as the flash access time is faster than the time it takes to run an instruction, it shouldn't matter.

The physical construction of RAM allows us to build very fast devices; much faster than flash. At this point, it makes sense to copy blocks of code into RAM before execution. This also brings additional benefits to the developer, such as being able to modify code at runtime.

in von Neumann architectures where the program and data memories share a bus but in Harvard architectures wouldn't this mean that all the code and data have to pass through the CPU registers first?

Not necessarily. This is where virtual addressing comes in. Instead of program code referring to the raw hardware RAM addresses, it actually references a virtual address space. Blocks of virtual address space are mapped over to physical memory devices, which may be RAM, ROM, flash, or even device buffers.

For example, when you reference address 0x000f0004 on a micro, you might be reading address 0x0004 from the flash. The virtual address is 0x000f0004, but the physical address is just 0x0004 - the entire 0x000fxxxx address space is mapped to a 4KB physical memory device. This is just an example, of course, and the method of managing and organising virtual address space vastly differs across architectures.

As such, when you say that "the program begins executing [...] from the address 0x0000 which is almost always the lowest address in flash", you're not guaranteed to be correct. In fact, many microcontrollers start at 0x1000.

Answer 3

What you are saying is not completely true or false. There are different scenarios for this.

That depends on whether you are programming on the raw hardware or on the hardware installed with OS.

Your operating system running on the general purpose computer fetches code from the H.D.D and stores it on the RAM for faster access. If your processor try to fetch directly from the HDD on ongoing basis then operations would be much slower due to speed mismatch between two. So your RAM comes into play where piece of your repetitive code is stored for faster access. And that too even further is made available on the processors cache memory to make it even more faster.

Now when you are working on micro controller it totally depends on you where you locate your data on the chip. If the data is static you might want to locate it on code memory which will save your RAM which is comparatively much smaller than Code memory. In C language when you initialize datatype using static or in some compiler const prefix data will be stored on the code memory or else will be stored in the RAM. And in the assembly you directly use DB (Define Byte in case of Basic 8051) to initialize data on the particular location. Now even in some controllers like PIC ARM you can write ROM in the run time but fetching data will take much time.

Plus there are Boot loader hardwares in medium level & sophisticated controllers which tells the controllers or processor where to execute the start up code from or it itself is the start up code which is actually is segmented into the memory So there are lots of possibilities due advancement, I would rather say hybrid advnacement in the industry which mishmashes the whole concept of conventional RAM ROM & memories. So basically your confusion is valid.