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

["Christophe" <christophe.avoinne@laposte.net>]

----- Original Message -----
From: Yann Guidon <whygee@f-cpu.org>
To: <f-cpu@seul.org>
Sent: Thursday, February 28, 2002 6:32 PM
Subject: Re: [f-cpu] virtually or physically-addressed cache ?


> hi,
>
> 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.

>
> ?????
>
> 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.

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. 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.

> I prefer to stick with (2) because in case of simultaneous access
> of the memories by different devices, the overhead is reduced.
> More precisely, the memory hierarchy in a multi-CPU system is
> globally/physically addressed but distributed among the CPU :
> each CPU has a "private" RAM range (allocated during bootup)
> and when it wants to access a location outside of its private range,
> it goes through the interconnexion network.

I aggree.

> 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 !!!!! how can I transfer data to
user memory (virtual addresses) when i'm in kernel mode !? Must I use a
function to translate a virtual address to a physical address !? hey !!! if
I have 16 pages to copy I must translate 16 times !?! 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).

/christophe

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