Re: [f-cpu] virtually or physically-addressed cache ?

[Yann Guidon <whygee@f-cpu.org>]

hello,

Christophe wrote:
> From: Yann Guidon <whygee@f-cpu.org>
> > Marco Al wrote:
> > > From: "Christophe" <christophe.avoinne@laposte.net>
> > > > Virtual or physical addressing ?
> > > > -------------------------------------------
> > > > (1) virtually-addressed caches (virtual tags)
> > > >
> > > > + do address translation only on a cache miss
> > > > + faster for hits because no address translation
> > >
> > > Another plus to this method, its the only way to go with software managed
> > > address translation AFAICS.
>
> But what happens if we have a L1 hit and get in fact a TLB miss
> (invalidation, read-only, etc.) ? our TBL would need to flush L1 to be
> synched with TLB before resuming the faulty instruction after a TLB
> exception.
>
> An exception must occur to validate our TLB with the right physical address
> for the faulty virtual address; at the end of exception, the faulty code may
> resume to access the virtual address back with success this time. So I don't
> see any difficulties with software managed address translation since L1 is
> not valid until the faulty code resumes.

fortunately, with the split address/access method in FC0, this is not a
big problem.

> > ?????
> >
> > Currently i plan and design a physically-addressed cache (2).
> > It adds a translation cycle but i don't see any other problem.
> > And since it is pipelined and the pipeline splits the operation
> > (access and addressing), the TLB lookup is not inside the visible
> > software latency (unless you program badly).
> 
> I'm rather looking first for a physically-addressed cache with physical
> tags.

i presume that i have a _little_ (hmmm) vocabulary problem.
what is the difference between physical tags and physical addressing ?...
currently i work in the following way : the application SW works with
"virtual/logical" addresses that are translated by the TLB to "physical"
addresses when going outside of the execution pipeline. So the L1 tags are
physical.

> A virtually-addressed cache but with physical tags (TLB translation works in
> parallel way to give us physical tags if any) could be very interesting and
> apparently a lot of race-cpu use it.
i don't understand exactly what it means...

> But there is one thing I'm not sure :
> what happens with different virtual addresses spanning the same physical
> address ? I must find more info about this third cache type.
and i'll gladly read your links and comments.

> > Concerning the cost of physical addressing from the CPU point of view,
> > i think i have found a way to reduce the cost to this of flat addressing
> > (ie in "kernel mode" when there is no TLB access). This also simplifies
> > the pipeline scheduler because there is no need to modify the timing :
> > kernel mode and vritual-addessed mode take the same time.
> > The big disadvantage is that it works better with only one page
> > granularity :-/
> 
> Kernel mode is only no-paging !? oh bad !!!!!
i didn't write "only". it just runs in "physical addressing mode/no TLB"
for the bootstrap and the IRQ. no big problem about that.
If you have a HURD or Linux kernel, you can still create tasks (TLB entries)
for specific code sections of the kernel, so you can swap them out.
However, the bootstrap is later overwritten, and the IRQ/trap/syscall handlers
are not likely to be swapped easily, otherwise the system could crash...

> how can I transfer data to
> user memory (virtual addresses) when i'm in kernel mode !?
as simply as in creating a TLB entry that points to the physical location
of the data, give the pointer to the task/process and voilą. why do you seek
complex problems ? :-)

> Must I use a
> function to translate a virtual address to a physical address !? hey !!!
it's the other direction : kernel will give the pointer, the userland process
will access the data through the new TLB entry. If the kernel pre-loads the TLB
entry, it's even faster (no trap on access).

> if I have 16 pages to copy I must translate 16 times !?!
you mean copy "as in block copy" ? why would you do that ?

> whereas if kernel mode
> can handle virtual address space (so it should be able to use TLB), I would
> just need to do a memcpy (or user_memcpy for Linux hacker).
kernel parts can be "virtualised", of course : their CMB (process descriptor)
would have all the enable bits on, or at least those which are necessary
(to help prevent security problems or bug propagation). but this is not necessary.

> /christophe
WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/