Jump to content

Memory/I-O Data Retrieve by Processor ?


maverick_spear

Recommended Posts

Hi I am studying the computer science Hardware. I have one question. I studied processor architecture and came to know that the processor sends the request of read and write commands to the memory unit if it doesn't see the data or instruction in its registers. The processor use to send these commands in bulk as these requests are buffer some where in the memory controller hub. But when the memory return back the data it simply sends the data so how does the processor knows that this data or instruction belongs to specific process or what mechanisms it will deployed to classify the information coming back from the memory or I/O. For example the processor sends the address and data to be fetched back from I/O and then again it sends the request to fetch but this time from memory. When the data returns its simply the bits so how does the processor classify that the particular information belongs to either the process deals with I/O or memory.

Link to comment
Share on other sites

In the case of I/O, currently are used techniques such as DMA (Direct memory access):

https://en.wikipedia.org/wiki/Direct_memory_access

f.e. hardware driver is setting address, length of buffer and other properties, operation is started and it's working parallel to CPU (transfer does not block CPU, like in old techniques)

At the end of data transfer CPU is informed about it, by special interrupt request IRQ.

https://en.wikipedia.org/wiki/Interrupt_request_(PC_architecture)

 

Link to comment
Share on other sites

Memory and I/O access (where done directly by the CPU, rather than DMA) are normally done sequentially, so the order the requests are sent is the same as the order in which the data are returned. That is how the CPU knows what instruction each access is associated with - just the next one in the queue.

To allow multiple asynchronous transfers then techniques like DMA are used, as Sensei says. In this case, it is the interrupt that is triggered at the end of the transfer which identifies the task that the data is for.

There are architectures that allow the CPU to make asynchronous memory and I/O accesses. In this case, the data can return out of order. This is handled by associating a "tag" value with each access that identifies where that data is supposed to go (e.g. which instruction or thread of processing).

Link to comment
Share on other sites

2 hours ago, maverick_spear said:

Hi I am studying the computer science Hardware. I have one question. I studied processor architecture and came to know that the processor sends the request of read and write commands to the memory unit if it doesn't see the data or instruction in its registers. The processor use to send these commands in bulk as these requests are buffer some where in the memory controller hub. But when the memory return back the data it simply sends the data so how does the processor knows that this data or instruction belongs to specific process or what mechanisms it will deployed to classify the information coming back from the memory or I/O. For example the processor sends the address and data to be fetched back from I/O and then again it sends the request to fetch but this time from memory. When the data returns its simply the bits so how does the processor classify that the particular information belongs to either the process deals with I/O or memory.

In a modern multi-core, multi-thread computer various Processing Units (PU). A PU may be synchronous simple or asynchronous complex; regardless, they use one memory bus port. The PU access memory by sending an address and request to either read or write the addressed memory. That Address Request (AR) is sent to a memory bus that several PU also use; it's basically a tiny network contained within the CPU. A cache (a small fast memory) receives the AR, if the cache contains data for that address, it satisfies the PU request. If the AR is a read, it sends the data stored in that address to the PU. Additionally, the cache may need to request the data from another memory, in which case, it reads the memory it uses. Often there are several layers of cache, for example the smallest is used by a single CPU core, and a larger ones shared by all the CPU cores. If the AR is a write, it saves the number provided by the PU into its cache and sends an write request to the next level of memory. See: cache, content addressable memory, translation lookaside buffer, CPU fully associative cache controllers.

Link to comment
Share on other sites

@EdEarl All these requests are data or instruction which is required to be received from the memory. It is received in the form of the bits so how does the cache identifies from bits received from the memory that it belongs to which PU. Did it add some tags with the data so that the memory controller when return back the data it adds a tag to that. 

Link to comment
Share on other sites

2 hours ago, maverick_spear said:

@EdEarl All these requests are data or instruction which is required to be received from the memory. It is received in the form of the bits so how does the cache identifies from bits received from the memory that it belongs to which PU. Did it add some tags with the data so that the memory controller when return back the data it adds a tag to that. 

The cache simply stores data that has been fetched (or written) so that if it is fetched again it will be quicker to access. The data is read from memory, store in the cache and also passed to the CPU (which knows what to do with it because of the ordering mentioned above). The cache stores the address the data came from (in a shortened form) along with the data.

This works because data accesses tend to be local: if the program accesses variable x it is likely to access x (and the nearby y) again. The cache stores a whole "chunk" of data from around the fetched data so any nearby data will also be accessed more quickly in future.

Link to comment
Share on other sites

There is a lot more to a processor than a counter: instruction decode, arithmetic-logic unit, registers, etc.

And the instruction counter wouldn't use a ripple counter as it has to be a synchronous counter that increments by 1 on each clock cycle.

Link to comment
Share on other sites

Yes ,But this has helped me a lot in visualizing the manipulations of the Bits , Flip Flop devices and switching .

So i thought it would help a bit

Anyway if you can understand this in more simpler forms , that would be nice .

 

Link to comment
Share on other sites

8 minutes ago, bimbo36 said:

Yes ,But this has helped me a lot in visualizing the manipulations of the Bits , Flip Flop devices and switching .

So i thought it would help a bit

Anyway if you can understand this in more simpler forms , that would be nice .

Fair enough. It is always important to understand the simpler circuits (counters, registers, logic functions) before getting to grips with how they are all put together to build adders, multipliers, and all the other functions that work together to make a CPU work.

21 hours ago, maverick_spear said:

Thanks strange and sensi I am actually doing self interest project of studying and making a control unit of the processor, If you could give me a reference about your information, I would be really thankful to you

I would struggle to provide references. I learned from books (before the Internet existed!), from courses and from work experience....

Link to comment
Share on other sites

23 hours ago, maverick_spear said:

@EdEarl All these requests are data or instruction which is required to be received from the memory. It is received in the form of the bits so how does the cache identifies from bits received from the memory that it belongs to which PU. Did it add some tags with the data so that the memory controller when return back the data it adds a tag to that. 

A memory bus transmits addresses plus requests and data in parallel, meaning memory addresses plus requests are transmitted in one clock from processor to bus over multiple wires that connect the memory subsystem. A processor can request various sizes of data from 8-bits to 128-bits, depending on program requirements. Thus, part of the memory subsystem splits wider data that cache and the memory subsystem transfer in a clock cycle into different sizes used by a processor. The cache and memory system may transmit huge words, for example 256 bits at a time. Chip designers try to match memory bandwidth with CPU chip performance, because multiple core chips can use more data than fewer cores.

A memory bus has multiple connections to processors, just as your local home network has multiple connections. Each device has an address that the network manages. When a memory request comes from device 1 on the bus, the reply goes to device 1 on the bus. Similarly, device 2, 3, etc. send and receive requests and data.

Link to comment
Share on other sites

3 minutes ago, EdEarl said:

A processor can request various sizes of data from 8-bits to 128-bits, depending on program requirements.

Depending on the type of processor, of course. There are still a heck of a lot of pure 8 and 16 bit processors out there (in embedded systems) that can only fetch 8 or 16 bits at a time.

But for most high-performance processors you are right. (And some fetch more than 128 bits at a time.)

Link to comment
Share on other sites

@Strange,

True, systems may be single thread, single processor, or more complex. A useful computer, with keyboard and display may have three processors: video, CPU and DMA. Thus, they must have the beginning of a complex memory system; although, far simpler than one for a multiple core system.

Edited by EdEarl
word choice
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.