[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



From: "Yann Guidon" <whygee@f-cpu.org>

> > With segments Im thinking of a set of registers which are indexed by the
> > MSB's of the address, the content of which replaces the "top" part of
the
> > address. Each segment would have its own set of protection flags.
>
> Don't pages do already do that ? ... huh ?

At a different granularity, a couple of segments would make up the entire
memory space for the process, and pages have physical memory beneath them
... the address after the segment has been prepended would still be pointing
to the global address space.

http://www.ee.umd.edu/~blj/papers/ieeetc50-5.pdf
http://www.ee.umd.edu/~blj/papers/computer31-6.pdf

Explain it "better" than me ... actually  I only just realised that I was a
little hung up on the SASOS idea (for which you dont need segments). With
the example mechanism in the first paper normal per process memory spaces
are actually pretty trivial. The underlying global memory space still has to
be larger than with a standard scheme, because it has to accomodate the
total size of all the process spaces put together, but I doubt the costs are
something simplification of the caches and removal of the TLB wont cover.
Also because segment id's can be expanded (creating larger addresses)
instead of replaced (which you would do in the 64 bit situation) it would
still be usuable when the architecture only used small pointers.

Mea culpa ... if you forget my ramblings and just read the first paper
you'll see its quite elegant apart from having to walk the cache for
invalidation and changing protection (the costs for either arent really
relevant as explained in the paper ... but even so when memory were to be
shared you would usually share it through the segment mechanism, if you have
per segment protection flags which can override the per cacheline one's you
cover 99% of the applications).

Marco

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