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

["Marco Al" <marco@simplex.nl>]

From: "Christophe" <christophe.avoinne@laposte.net>

> Ok, lookup at this case (something like a memory pipe) in the same address
> space :
>
> - a thread wants to share a memory space where it could only read.
> - another thread wants to share the same memory space where it could only
> write.
>
> The only solution is having two different virtual addresses with different
> access rights pointing upon the same physical addresses.
>
> With virtual-addressed cache and virtual tags, the thread wouldn't read
> the right value after the other
> thread write because they use different entries in the cache.
>
> So even with your lazy solution, it is still impossible to do so.

Threads are scheduled by the OS, if you really wanted to the OS could just
change the protection when it switches between threads (with the method
described in the section in the paper I pointed out before). As I conceded
before you need individual protection spaces, but that does not equal
individual memory spaces.

Alternatively/additionally you could use a segment based approach with per
segment protection flags and just change the segment registers when
switching threads ... with variable sized segments that would work out
pretty well IMO, an important aspect is that it can work with SMT.

> An extended case : 1 provider, n consumers
>
> - a thread wants to share a memory space where it could read and write.
> - n threads wants to share the same memory space where it could only read.

The same solution as above applies.

What I dont understand is why you would want to use memory mapped to two
seperate memory ranges within the same process, because the memory isnt
really protected ... the thread which is only supposed to read can still
just write to the page through the other mapping ... shrug, anyway Ill just
repeat that if you really wanted to you could do it even with a global
address space.

> My opinion is that we should never try to put anything in the sofware
> corner. The end user is not an
> hardware person but a software person who would like to have choice to use
> a unique address space or
> seperate address spaces for his/her processes.

The set of users who could not get over it probably share a good number of
people with the set of users who want machine's with lots of speculation,
instruction reordering, huge caches and automatic prefetch mechanisms ...
all there to mitigate the performance hit poorly targeted and implemented
software gets. FCPU is not the processor for that second set of people, and
I doubt very many of the first group remain afterwards.

You would hope that the average user which is already ready to accept the
FCPU would also recognise it when this mechanism would provide him with
everything he needed, which is still open for debate, even if it means doing
some things differently ... and is more appreciative what allowing
simplification of the hardware and removal of the TLB bottleneck gives him
in performance and cost terms.

>Your software solution happens not to fullfil all the
> requirements that a hardware solution (virtual/physical-addressed cache
> but with physical tags) can fullfil.

Maybe, but you have yet to come up with a realistic scenario where it would
be a problem :) (apart from people having to change their way's a bit, which
is always a problem ... but unfortunately unavoidable, the FCPU architecture
stray's from the usual superscalar RISC approach regardless of how it
implements virtual memory)

Marco

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