Dynamic areas: meaning of "bufferable"?
Dave Higton
Dynamic Area? I understand cacheable, but not bufferable.
Dave
Sprow
> What does "area is bufferable" mean in the context of a RISC OS
> Dynamic Area? I understand cacheable, but not bufferable.
It's a feature of the MMU.
Google "arm mmu bufferable bit" and pick one of the results. I think
that while at the MMU level the exact implementation varies from ARM
to ARM, RISC OS hides this away from you via the API,
Sprow.
druck
> What does "area is bufferable" mean in the context of a RISC OS
> Dynamic Area? I understand cacheable, but not bufferable.
It means the write buffer can be used on it, i.e. normal memory.
You would not set this bit if the area was addressing real hardware
which needed to receive all writes without coalescing and reordering.
---druck
Dave Higton
druck <ne...@druck.org.uk> wrote:
My thanks to both Sprow and you.
It's not clear to me what would happen if the CPU wrote to bufferable
memory and then read back immediately. Is it guaranteed that the
write will complete before the read? Or does the read take place
from the write buffer instead of the external memory?
It must be very difficult to test, though, in reality - and, therefore,
to see a problem in the real world.
Dave
Martin Wuerthner
Dave Higton <daveh...@dsl.pipex.com> wrote:
> In message <hhur9l$org$2...@news.eternal-september.org>
> druck <ne...@druck.org.uk> wrote:
>> Dave Higton wrote:
>>> What does "area is bufferable" mean in the context of a RISC OS
>>> Dynamic Area? I understand cacheable, but not bufferable.
>>
>> It means the write buffer can be used on it, i.e. normal memory.
>>
>> You would not set this bit if the area was addressing real hardware
>> which needed to receive all writes without coalescing and reordering.
> My thanks to both Sprow and you.
> It's not clear to me what would happen if the CPU wrote to bufferable
> memory and then read back immediately. Is it guaranteed that the
> write will complete before the read? Or does the read take place
> from the write buffer instead of the external memory?
You do not have to worry how he CPU does it. It simply guarantees that
your code sees the correct result, i.e., the same result as if the
write had happened immediately.
Martin
--
---------------------------------------------------------------------
Martin Wuerthner MW Software http://www.mw-software.com/
ArtWorks 2 -- Designing stunning graphics has never been easier
spam...@mw-software.com [replace "spamtrap" by "info" to reply]
Dave Higton
Martin Wuerthner <spam...@mw-software.com> wrote:
> In message <197704d550...@dsl.pipex.com>
> Dave Higton <daveh...@dsl.pipex.com> wrote:
>
> > In message <hhur9l$org$2...@news.eternal-september.org>
> > druck <ne...@druck.org.uk> wrote:
>
> >> Dave Higton wrote:
> >>> What does "area is bufferable" mean in the context of a RISC OS
> >>> Dynamic Area? I understand cacheable, but not bufferable.
> >>
> >> It means the write buffer can be used on it, i.e. normal memory.
> >>
> >> You would not set this bit if the area was addressing real hardware
> >> which needed to receive all writes without coalescing and reordering.
>
> > My thanks to both Sprow and you.
>
> > It's not clear to me what would happen if the CPU wrote to bufferable
> > memory and then read back immediately. Is it guaranteed that the
> > write will complete before the read? Or does the read take place
> > from the write buffer instead of the external memory?
>
> You do not have to worry how he CPU does it. It simply guarantees that
> your code sees the correct result, i.e., the same result as if the
> write had happened immediately.
I thought that would be the case, but I could see nothing in the
documents I read that mentioned whether or how it was solved.
Dave
druck
> It's not clear to me what would happen if the CPU wrote to bufferable
> memory and then read back immediately. Is it guaranteed that the
> write will complete before the read? Or does the read take place
> from the write buffer instead of the external memory?
The CPU will snoop from the write buffer, so it sees a consistent
behaviour. However the target of the write (memory or device) may see a
write before a read, just a write, or even nothing. That's why devices
must not be buffered.
> It must be very difficult to test, though, in reality - and, therefore,
> to see a problem in the real world.
It's not difficult to test, you just have to understand the rules.
---druck