http://bugzilla.gdcproject.org/show_bug.cgi?id=126
Mike <slavo5...@yahoo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |slavo5...@yahoo.com
--- Comment #7 from Mike <slavo5...@yahoo.com> ---
As I understand it, there are 2 issues to be addressed by 'volatile' or some
other solution.
1. Ensure a memory location is always read/written and not cached in registes
2. Ensure instructions that access 'volatile' memory are not reordered by the
compiler.
I believe 'shared' satisfies (1), but not (2). A 'volatile' memory location is
one which the executing thread does not have complete control of, and can
therefore be changed by some other entity external to the executing thread.
Therefore is it's contents are volatile.
I think of 'shared' similarly. The memory location is shared by the executing
thread with other external entities: other threads, other processors, a
sensor, or other peripheral that may read or write to that memory location
outside of the context of the executing thread. What 'shared' doesn't satisfy
is (2).
peek() and poke() intrinsics would satisfy both (1) and (2).
I see at least 3 solutions:
1. Add volatile semantics with either a keyword or an attribute requiring
compilers to address both (1) and (2)
2. Use 'shared' to address requirement (1) and add some other "don't reorder"
feature to the front-end
3. Add peek() and poke() intrinsics.
I prefer (2), (3), then (1). I prefer (2) simply because it is more granular
and both 'shared' and a "don't reorder" feature could be used for other
purposes outside of my immediate need which is peripheral memory mapped IO.
--
You are receiving this mail because:
You are watching all bug changes.
