Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

How we access RAM or ROM memory

  1. Aug 28, 2014 #1
    how we access memory and which instruction we use that determine weather we are accessing Internal rom , Internal Ram ?

    how to access rom

    example
    Mov R0, #55H ; load R0 with 55H
    Mov R1, #85H ; load R1 with 85H


    how to access ram memory
    Mov 00, #55H ; ram location 00 has 55H data
    Mov 01 , #85H : ram location 01 has 85H data

    what is difference between rom address and Ram location
     
  2. jcsd
  3. Aug 29, 2014 #2

    Simon Bridge

    User Avatar
    Science Advisor
    Homework Helper
    Gold Member
    2016 Award

    ROM cannot be written to.
    By "access" do you mean "read"?

    "reading" RAM (iirc) involves a read and a write operation (reading the bit depletes it). ROM only needs a read.
    Often done by a different instruction in the machine language so the CPU knows what to do - which is why you may have a different instruction-label in the human-readable level code you are using. But the label may just be a hangover from older-style operations.
     
  4. Aug 29, 2014 #3

    SteamKing

    User Avatar
    Staff Emeritus
    Science Advisor
    Homework Helper

    Both RAM and ROM use the same type of addresses: the programmer must know something about the internal organization of the hardware for a particular computer to determine which address locations are reserved for ROM and which are reserved for RAM

    As an example, here is a basic IBM PC memory map:

    http://www.tec.sci.fi/tecref/addrmap.gif

    The memory map is on the right, and the addresses run from 0000H to FFFFH.
     
  5. Aug 29, 2014 #4

    phinds

    User Avatar
    Gold Member
    2016 Award

    True for dynamic RAM, not true for all RAM. Admittedly, pretty much all RAM IS dynamic RAM these days but that doesn't make your statement universally true.

    Seems unlikely since the CPU is indifferent to the kind of memory it is fetching from. The MEMORY chip may do a local re-write, but that's not the job of the CPU or its instruction set.
     
  6. Aug 29, 2014 #5

    Mark44

    Staff: Mentor

    Minor aside: The memory map and addresses that SteamKing posted are very old (~30 years).
     
  7. Aug 29, 2014 #6

    berkeman

    User Avatar

    Staff: Mentor

    Yeah, but it still made me smile! :smile:
     
  8. Aug 29, 2014 #7

    phinds

    User Avatar
    Gold Member
    2016 Award

    Yeah, me too. !
     
  9. Aug 29, 2014 #8

    Simon Bridge

    User Avatar
    Science Advisor
    Homework Helper
    Gold Member
    2016 Award

    Which seems unlikely?

    It's been a while since I had to handle hardware at that level though.
    I think post #1 is highlighting an apparent difference in the label for the instruction to read a rom vs reading ram. Usually a different name indicates a different machine language instruction - but I don't see why it has to.
     
  10. Aug 29, 2014 #9

    berkeman

    User Avatar

    Staff: Mentor

    For the circuits I work with, ROM and RAM are just at different addresses. DRAM refresh is handled by the DRAM circuit, independent of any accesses by the processor.
     
  11. Aug 29, 2014 #10

    SteamKing

    User Avatar
    Staff Emeritus
    Science Advisor
    Homework Helper

    Without knowing the particular CPU or its instruction set, the OP's question is kind of vague, then.

    I posted the early PC memory map to show that the RAM/ROM memory uses similar hexadecimal numbers to identify memory locations. The design of the particular computer using that CPU will specify the range of memory locations where the programmer can expect to find RAM or ROM memory. If a particular computer design does not follow the PC layout, then obviously the PC memory map will not be applicable.

    In other words, the programmer cannot write a general assembly program without knowing something about the hardware on which the program will be executed.
     
  12. Aug 29, 2014 #11

    phinds

    User Avatar
    Gold Member
    2016 Award

    Exactly my point. Simon Bridge, this response is also in answer to your question as to what I find unlikely. It's very unlikely that CPU's have different instructions for ROM/RAM.
     
  13. Aug 29, 2014 #12

    phinds

    User Avatar
    Gold Member
    2016 Award

    Agreed, but this does NOT mean that the CPU needs different instructions to access ROM vs RAM, just that the programmer needs to know what addresses to use.
     
  14. Aug 29, 2014 #13

    nsaspook

    User Avatar
    Science Advisor

    That's correct.
    The type of addressing instructions used with RAM or ROM depends on the CPU architecture. For a typical 'Pure' Harvard_architecture machine commonly seen on micro-controllers and DSPs the memory buss is separated and there are different instructions with possibility overlapping address spaces to access each. The instruction memory is usually ROM or flash with a separate R/W data memory path.
    A machine like the x86 is a modified Harvard processor core with separate instructions but with a common address space cache for the ROM and RAM. Usually only kernel hackers or embedded programmers operate at this level of programming on modern machines as a HLL like C commonly uses a internal 'fat' pointer to tell what type of access to use when linking the source code to ASM on Harvard architecture. :smile:

    http://en.wikipedia.org/wiki/Modified_Harvard_architecture
     
    Last edited: Aug 29, 2014
  15. Aug 30, 2014 #14

    phinds

    User Avatar
    Gold Member
    2016 Award

    Are you sure about that? I thought that x86 class machines were all straight von Neumann architecture.
     
  16. Aug 30, 2014 #15

    AlephZero

    User Avatar
    Science Advisor
    Homework Helper

    It depends whether you are talking about machine code or assembly language mnemonics. Most assemblers have gone in the direction of "overloading" the mnemonics to make it easier for humans to program - i.e. "mov" in assembler will move data from anywhere to anywhere, depending on the type of its operands, but the machine code to perform different types of move may be very different.

    The biggest machine code differences are between accessing the data registers on the chip and external memory, and there may be different instructions for accessing memory via special CPU registers like the stack pointer.

    IIRC, the basic architecture of an x86 didn't care whether you have RAM or ROM, or even nothing at all, connected to any particular address. If you try to write to ROM the operation fails, but the CPU doesn't care. The memory map diagram shows the standard configuration for an IBM-compatible PC, not for an x86 CPU chip.

    There are a few "essentials" in the hardware configuration - e.g. when the CPU powers up, it instruction pointer has to be pointing at some valid code to execute, and there must be some RAM somewhere for the call stack, if the hardware uses interrupts. (Conceptually, you don't actually need the stack just to run code, so long as you never use subroutines!). but apart from those few essentials, you can build the hardware almost any way you want, if you don't care about it being PC compatible.
     
    Last edited: Aug 30, 2014
  17. Aug 30, 2014 #16

    nsaspook

    User Avatar
    Science Advisor

    It's really a matter of what the programmer sees vs what's inside the box. The separation is at the L1 CPU cache, at this point there are separate instruction and data caches for the internal execution unit to process CISC instruction/data in microcode. The x86 instruction set is not really native to the execution unit anymore, it's micro-coded to emulate a von Neumann architecture from main memory so it's possible to fix some CPU bugs now with a microcode update.
    For example in Linux it's possible to update the microcode during the boot cycle.

    The CPU Harvard capability can also be used directly with great care by invalidating the cache buffers with certain types of faults to desynchronize/invalidate them and then load separate TLB entries for distinct memory spaces for code and data to provide a pure Harvard VM for kernel protection from almost any virus/rootkit attack. It's also possible to do some very nasty things with this method.
     
    Last edited: Aug 30, 2014
  18. Aug 30, 2014 #17

    phinds

    User Avatar
    Gold Member
    2016 Award

    nsaspook, that's interesting stuff. I hadn't been keeping up and was not aware of it. Thanks.
     
  19. Aug 30, 2014 #18

    nsaspook

    User Avatar
    Science Advisor

    I won't link directly to it but here is a google search.

    split TBL
     
  20. Aug 30, 2014 #19

    phinds

    User Avatar
    Gold Member
    2016 Award

    Cool. thanks again
     
Know someone interested in this topic? Share this thread via Reddit, Google+, Twitter, or Facebook