By: Ricardo B (ricardo.b.delete@this.xxxxx.xx), May 30, 2013 4:41 pm
Room: Moderated Discussions
Sebastian Soeiro (sebastian_2896.delete@this.hotmail.com) on May 30, 2013 1:13 pm wrote:
> Ricardo B (ricardo.b.delete@this.xxxxx.xx) on May 30, 2013 11:18 am wrote:
> > Sebastian Soeiro (sebastian_2896.delete@this.hotmail.com) on May 30, 2013 9:48 am wrote:
> >
>
> - Does the prefetcher use data path bandwidth aggressively? Or does it simply use it when there is "free
> bandwidth" to load predicted data needed? I'd imagine that the latter would be most beneficial and safe.
Probably the later. But again, only God and Intel know for sure.
>
> - So the stores come from instructions, hrm... So if an instruction was something like: (mul a,b
> = c), it would store c back into memory? Does that go directly into memory, or through the caches?
> If it goes directly to memory, does that have it's own path dedicated to this purpose?
"Store" is a term for writing to memory.
If "c" is a memory destination, then it goes to memory.
Stores to normal memory go to the caches. Before the store is actually done, the L1 D$ will get the relevant cache line (a 64B block) and the store will be done to the L1 $D.
Eventually, that cache line will be evicted to L2, ... and then memory.
> > > - So it does seem that a virtual address is a "tag" that the AGU generates for use by the execution
> > > units. So, the flow seems to be; ROB> Data Scheduler AGU (converts instruction addresses/physical
> > > into virtual addresses) DTLB? If this is correct, I have a question that probably has a really
> > > obvious answer... Why can't instruction's just use the physical address itself instead of some
> > > encrypted address for the AGU to figure out? And moreso, why does the CPU need to use virtual
> > > addresses? Why can't it just use physical addresses the whole time?
The AGU just does not convert physical into virtual addresses. It just does math with the virtual addresses.
An x86 address can be something as simple as [EDX], which means the virtual address is the numer held in register EDX.
Or it can be [EBX + 4*ESI + 39], which means the virtual address is the result of that calculation. The AGU is the block that performs that calculation.
It's the TLB which then translates virtual addresses into physical addresses.
Virtual and physical addresses are a key feature to implement a modern OS.
First and foremost, it's the mechanism by which (most) OS stop programs from reading and writing into each other's memory. This provides security and robustness.
It allows each program to have it's own large virtual address space.
And it allows for more efficient use of physical memory. A program can have a 1 MB array as 1 million consecutive addresses, while the OS actually maps it to any free physical page it has.
It also allows OS to swap parts of memory to disk transparently to programs.
Simple/older CPUs only deal with physical addresses. But you can't run a modern OS in one of those.
> Ricardo B (ricardo.b.delete@this.xxxxx.xx) on May 30, 2013 11:18 am wrote:
> > Sebastian Soeiro (sebastian_2896.delete@this.hotmail.com) on May 30, 2013 9:48 am wrote:
> >
>
> - Does the prefetcher use data path bandwidth aggressively? Or does it simply use it when there is "free
> bandwidth" to load predicted data needed? I'd imagine that the latter would be most beneficial and safe.
Probably the later. But again, only God and Intel know for sure.
>
> - So the stores come from instructions, hrm... So if an instruction was something like: (mul a,b
> = c), it would store c back into memory? Does that go directly into memory, or through the caches?
> If it goes directly to memory, does that have it's own path dedicated to this purpose?
"Store" is a term for writing to memory.
If "c" is a memory destination, then it goes to memory.
Stores to normal memory go to the caches. Before the store is actually done, the L1 D$ will get the relevant cache line (a 64B block) and the store will be done to the L1 $D.
Eventually, that cache line will be evicted to L2, ... and then memory.
> > > - So it does seem that a virtual address is a "tag" that the AGU generates for use by the execution
> > > units. So, the flow seems to be; ROB> Data Scheduler AGU (converts instruction addresses/physical
> > > into virtual addresses) DTLB? If this is correct, I have a question that probably has a really
> > > obvious answer... Why can't instruction's just use the physical address itself instead of some
> > > encrypted address for the AGU to figure out? And moreso, why does the CPU need to use virtual
> > > addresses? Why can't it just use physical addresses the whole time?
The AGU just does not convert physical into virtual addresses. It just does math with the virtual addresses.
An x86 address can be something as simple as [EDX], which means the virtual address is the numer held in register EDX.
Or it can be [EBX + 4*ESI + 39], which means the virtual address is the result of that calculation. The AGU is the block that performs that calculation.
It's the TLB which then translates virtual addresses into physical addresses.
Virtual and physical addresses are a key feature to implement a modern OS.
First and foremost, it's the mechanism by which (most) OS stop programs from reading and writing into each other's memory. This provides security and robustness.
It allows each program to have it's own large virtual address space.
And it allows for more efficient use of physical memory. A program can have a 1 MB array as 1 million consecutive addresses, while the OS actually maps it to any free physical page it has.
It also allows OS to swap parts of memory to disk transparently to programs.
Simple/older CPUs only deal with physical addresses. But you can't run a modern OS in one of those.
