0
\$\begingroup\$

From https://electronics.stackexchange.com/a/224160/150597 is it necessory that the code and data should be loaded in RAM before execution for Von neumenn architecture. While in harward arch. the code can be executed from ROM and data can be loaded from RAM??

What if only busses are based on harvard archi. (ARM) and the address space is still unified (similar to von neumenn except busses)? In von neumenn cant we execute code from ROM space?

\$\endgroup\$
6
  • \$\begingroup\$ Short answer is yes, for Von Neumann architecture with a unified address space the RAM and any ROM appear at different addresses and code can be executed from ROM. Note that sometimes the ROM is much slower than DRAM so the bootloader may copy code to RAM early on in its execution. \$\endgroup\$ – pjc50 Sep 6 '17 at 8:52
  • \$\begingroup\$ @pjc50 i know that RAM RoM will appear at different addresses in unified memory map. My question is should both code and data need to be loaded in RAM in von-neumenn arch. as mentioned in the answer link mentioned in my question?? More simplifing the question, kindly explain the answer whose link is given in the question!! \$\endgroup\$ – Aimal Sep 8 '17 at 11:51
  • \$\begingroup\$ In Von Neumann you can execute code from ROM space without loading it into RAM. \$\endgroup\$ – pjc50 Sep 8 '17 at 12:01
  • \$\begingroup\$ Dear @pjc50, And in harvard architecture?? \$\endgroup\$ – Aimal Sep 8 '17 at 12:02
  • 1
    \$\begingroup\$ In "pure" harvard you can't, code and data are completely separate. There aren't many of these around, PIC is the one you might actually encounter. \$\endgroup\$ – pjc50 Sep 8 '17 at 12:27
2
\$\begingroup\$

Wow. I didn't actually read all of that EESE exchange! Too much to have to process other than to focus on what little you asked. So I'll focus on that.

In von Neumann architectures, broadly speaking, a program has the following appearance:

        Section Description     Access          Non-Volatile     Size
        -----------------------------------------------------------------------
        Code                    Execute              Yes         Fixed/static
        Constants               Read                 Yes         Fixed/static
        Initialized Data        Read/Write           Yes         Fixed/static
        Uninitialized Data      Read/Write           No          Fixed/static
        Heap                    Read/Write           No          Variable, up
        Stack                   Read/Write           No          Variable, down

The code section can be execute-only, as it often is with the x86 family. But (obviously) the operating system must write it, somehow, before starting the program. If this is an embedded, stand-alone target without an operating system involved, it is usually stored in non-volatile memory or else it is fetched from secondary non-volatile memory (which is very often done without any extra software using the built-in ROM boot loader found in the ADSP-21xx DSP from Analog Devices.) During execution, it can be non-volatile (if there's no need to modify it at run-time) or it can be volatile (if modifications are required -- such as what may happen with late binding.)

As you can see, it might be possible for a compiler to arrange for all of code, constants, and initialized data to reside in non-volatile memory somewhere. There's no need to store any of the last three sections mentioned in the table above in non-volatile memory, though.

The above table is almost correct. However, note that the initialized data section does require read-write access. Since almost all non-volatile memory isn't easily writable, except for FeRAM (or FRAM), this is almost always stored in RAM that is transferred out of non-volatile storage (primary or secondary) into the RAM just prior to starting the code (other than the start-up code that you usually don't see or write.) This means the above table probably should be:

        Section Description     Access          Non-Volatile     Size
        -----------------------------------------------------------------------
        Code                    Execute              Yes         Fixed/static
        Constants               Read                 Yes         Fixed/static
        Initialized Data Copy   Read                 Yes         Fixed/static
        Initialized Data        Read/Write           No          Fixed/static
        Uninitialized Data      Read/Write           No          Fixed/static
        Heap                    Read/Write           No          Variable, up
        Stack                   Read/Write           No          Variable, down

The above table now highlights the fact that the initialized data section must reside in two places -- non-volatile memory (such as flash) and volatile memory (SRAM) and that there needs to be start-up code that transfers data from the initialized data copy section to the initialized data section. But still remember that some processors, such as certain MSP430's that are built with FRAM, can keep the initialized data in their non-volatile memory. So either one of the tables might be correct.


The heap section isn't static at run time. Normally, this section is set up having zero size to start and then grows and shrinks during execution. This is the area used by routines like malloc(), for example. A simple design for the heap has it growing upwards and away from the last memory location required by all the static data areas and towards the stack.

The stack section also isn't static at run time. Normally, this section also starts out with zero size and grows and shrinks during execution. This is usually where function parameters and local, "auto" variables reside. It's also used by the C compiler for temporary storage, spilling registers, etc. And it usually grows downward and away from the last possible memory location for the program and towards the growing end of the heap section. In this fashion, there is a single, invisible area of read-write memory, a "no man's land" so to speak, between the heap and the stack, which each section grows "into" like a candle burning at both ends. If, during execution, the heap grows into the stack (or visa versa) then the program will probably fail to operate correctly.


In Harvard architectures, there are at least two different memory systems -- one for code access and one for data access. Usually, there are specialized instructions which permit reading from the code memory system, treating it as data. Here, the details get a little more complex than above.

When the system starts up, the code, constants, and initialized data must be available. Since different memory systems are involved, and since all of the data must be accessed via the data memory system, the startup code usually copies out values required for the initialized data section and for the constants section into data SRAM where it can be treated as regular data.

So the Harvard table might look like this:

        Section Description     Access          Non-Volatile     Size
        -----------------------------------------------------------------------
        Code                    Execute              Yes         Fixed/static
        Constants Copy          Read                 Yes         Fixed/static
        Initialized Data Copy   Read                 Yes         Fixed/static
        Constants               Read/Write           No          Fixed/static
        Initialized Data        Read/Write           No          Fixed/static
        Uninitialized Data      Read/Write           No          Fixed/static
        Heap                    Read/Write           No          Variable, up
        Stack                   Read/Write           No          Variable, down

Here, the start-up code must transfer the constants copy section to the constants section and then also transfer the initialized data copy section to the initialized data section, before letting the program continue further.


To directly answer your question about being able to execute code directly from ROM with von Neumann, yes you can. In fact, it's often done that way. You just burn the code into flash. That works for both types, just fine.

(And multiprocessing and threads complicate the above tables further.)

\$\endgroup\$
6
  • \$\begingroup\$ thanks you very well explained the memory layout but that nice explanation didn't remove my doubts. I am still confused, Do we MUST need to keep both code and data in one memory in von Neumenn arch as there is one bus?? "Yes we can" seems to be sort of exception. The question is do we need to do so?? In simple words does there exist any difference in boot process of both harvard and von-neumenn arch.??? \$\endgroup\$ – Aimal Sep 8 '17 at 11:46
  • \$\begingroup\$ The word "Exception" in above comment may please be considered/read as "Possibility". \$\endgroup\$ – Aimal Sep 8 '17 at 12:04
  • \$\begingroup\$ @Aimal I don't understand your confusion. Your writing is difficult for me to parse. von Neumann is, by definition, a single address and therefore a single bus. There is no conflict in mixing several types of memory on a single bus. \$\endgroup\$ – jonk Sep 8 '17 at 13:58
  • \$\begingroup\$ @pjc50 gives a clue perhaps - on boot, in pure harvard architecture you can't combine code and data, they are always in seperate memory spaces. And in von neumenn it can be combined in single memory space via a bootloader as we do during debugging.. i.e. we load everything in RAM memeory as we frequently change code and load it again and again. \$\endgroup\$ – Aimal Sep 8 '17 at 16:24
  • \$\begingroup\$ @Aimal I think I explicitly mentioned the different memory spaces. I just now highlighted (bolding) the place where I pointed it out. Because there may be two (or more) address buses in Harvard, there must be special instructions or else complex memory mapping hardware (segmented memory, as in Multics/x86, could be an example if it were later mapped onto multiple address spaces) to divert a request to the appropriate bus. \$\endgroup\$ – jonk Sep 8 '17 at 17:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.