How we access RAM or ROM memory

[vead]

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

 

[Simon Bridge]

what is difference between rom address and Ram location

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.

 

[SteamKing]

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.

 

[phinds]

"reading" RAM (iirc) involves a read and a write operation (reading the bit depletes it).

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.

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.

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.

 

[Mark44]

Minor aside: The memory map and addresses that SteamKing posted are very old (~30 years).

 

[berkeman]

Minor aside: The memory map and addresses that SteamKing posted are very old (~30 years).

Yeah, but it still made me smile!

 

[phinds]

Yeah, but it still made me smile!

Yeah, me too. !

 

[Simon Bridge]

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.

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.

 

[berkeman]

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.

 

[SteamKing]

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.

 

[phinds]

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.

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.

 

[phinds]

In other words, the programmer cannot write a general assembly program without knowing something about the hardware on which the program will be executed.

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.

 

[nsaspook]

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.

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.

http://en.wikipedia.org/wiki/Modified_Harvard_architecture

 

[phinds]

... A machine like the x86 is a modified Harvard processor core

Are you sure about that? I thought that x86 class machines were all straight von Neumann architecture.

 

[AlephZero]

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.

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.

 

[nsaspook]

Are you sure about that? I thought that x86 class machines were all straight von Neumann architecture.

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.

 

[phinds]

nsaspook, that's interesting stuff. I hadn't been keeping up and was not aware of it. Thanks.

 

[nsaspook]

nsaspook, that's interesting stuff. I hadn't been keeping up and was not aware of it. Thanks.

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

split TBL

 

[phinds]

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

split TBL

Cool. thanks again