By: dmcq (dmcq.delete@this.fano.co.uk), April 23, 2015 4:54 am
Room: Moderated Discussions
Jouni Osmala (yeah.delete@this.right.com) on April 23, 2015 3:19 am wrote:
>
> > > Load/store operations are dealt with outside of the execution core. As mentioned in the documentation
> > > the core only contains AGUs whose outputs are sent to a piece of external machinery that is responsible
> > > for executing loads and stores and dealing with their variable-latency nature. Loads can be executed
> > > early and their results held in a temporary buffer to be fed to the execution core when an instruction
> > > requires them. This arrangement explains in my eyes why the Mill doesn't have conventional virtual memory
> > > addressing. Having it would require a TLB-like structure which is also variable-latency by nature and
> > > couldn't be integrated easily in a data-flow execution core. If the result of a load is not available
> > > when a dependent instruction is expected to run then the entire execution core is stalled waiting for
> > > it. The load/store machinery (unit?) is thus decoupled
> > > from the execution core (and from the AGUs, something
> > > that was mentioned multiple times) and operates asynchronously from it.
> >
> > There is a TLB-like structure that handles protection, the PLB. However checking can be
> > done in parallel with the load, rather than in front of it as in a conventional TLB.
>
> But almost every TLB works parallel with load instead of front of it and is primary reason why minimum
> page size affects the cache design so much and why I always claim it would be really nice to have
> bigger linear translation between physical and virtual addresses than 4k minimum page size.
>
>
> And little reply to this point.
> http://millcomputing.com/wiki/Protection#Region_Table
>
> And they need to be faster than L1 accesses for any modern design.
> Virtually tagged L1 caches don't work with SMT and is bad for modern requirement of running
> lots of active processes and threads. I would really like if it would be option for CPU
> to have virtually tagged L1 cache and TLB would only be needed for L2 cache but it isn't
> an option, when you need to handle lots of context switches and coherency traffic.
Assuming the virtual address would be extended by a process id for non system memory. A virtually addressed cache would work okay provided one could ensure there weren't any aliases in it. A way of doing that is for the L2 cache to say if some memory is cached in the L1 cache. Then if an address failed lookup in the L1 cache but the L2 cache said it was in the L1 cache then the data would have to be moved in the L1 cache to match the new virtual address.
An optimisation would be to have another bit of L1 cache which worked with physical addresses but was slower because a translation lookup needed to be done. In this case if a lookup failed but the L2 cache said it was in L1 then the data would have to be moved from the virtually addressed cache to the physically addressed one.
There's probably a bit more to it but I can see opportunities to speed up the cache and save power on lookups with something like this. In fact I'm surprised it isn't already done so either there's problems I haven't seen or there is a good chance it actually is in use somewhere or people think it all works well enough currently with a pipeline so it just isn't worth bothering with.
>
> > > Load/store operations are dealt with outside of the execution core. As mentioned in the documentation
> > > the core only contains AGUs whose outputs are sent to a piece of external machinery that is responsible
> > > for executing loads and stores and dealing with their variable-latency nature. Loads can be executed
> > > early and their results held in a temporary buffer to be fed to the execution core when an instruction
> > > requires them. This arrangement explains in my eyes why the Mill doesn't have conventional virtual memory
> > > addressing. Having it would require a TLB-like structure which is also variable-latency by nature and
> > > couldn't be integrated easily in a data-flow execution core. If the result of a load is not available
> > > when a dependent instruction is expected to run then the entire execution core is stalled waiting for
> > > it. The load/store machinery (unit?) is thus decoupled
> > > from the execution core (and from the AGUs, something
> > > that was mentioned multiple times) and operates asynchronously from it.
> >
> > There is a TLB-like structure that handles protection, the PLB. However checking can be
> > done in parallel with the load, rather than in front of it as in a conventional TLB.
>
> But almost every TLB works parallel with load instead of front of it and is primary reason why minimum
> page size affects the cache design so much and why I always claim it would be really nice to have
> bigger linear translation between physical and virtual addresses than 4k minimum page size.
>
>
> And little reply to this point.
> http://millcomputing.com/wiki/Protection#Region_Table
>
> And they need to be faster than L1 accesses for any modern design.
> Virtually tagged L1 caches don't work with SMT and is bad for modern requirement of running
> lots of active processes and threads. I would really like if it would be option for CPU
> to have virtually tagged L1 cache and TLB would only be needed for L2 cache but it isn't
> an option, when you need to handle lots of context switches and coherency traffic.
Assuming the virtual address would be extended by a process id for non system memory. A virtually addressed cache would work okay provided one could ensure there weren't any aliases in it. A way of doing that is for the L2 cache to say if some memory is cached in the L1 cache. Then if an address failed lookup in the L1 cache but the L2 cache said it was in the L1 cache then the data would have to be moved in the L1 cache to match the new virtual address.
An optimisation would be to have another bit of L1 cache which worked with physical addresses but was slower because a translation lookup needed to be done. In this case if a lookup failed but the L2 cache said it was in L1 then the data would have to be moved from the virtually addressed cache to the physically addressed one.
There's probably a bit more to it but I can see opportunities to speed up the cache and save power on lookups with something like this. In fact I'm surprised it isn't already done so either there's problems I haven't seen or there is a good chance it actually is in use somewhere or people think it all works well enough currently with a pipeline so it just isn't worth bothering with.