http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #20 from Iain Buclaw ---
(In reply to Mike from comment #19)
> Oh, and about atomic access... I agree that memory-mapped IO is shared,
> global state, but I also agree that it is wasteful to wrap each and every
> access in atomic acce
On Sunday, 15 June 2014 at 11:28:22 UTC, Iain Buclaw wrote:
On Wednesday, 11 June 2014 at 09:24:05 UTC, Iain Buclaw wrote:
Hi,
I'm in the process of switching over the gdcproject.org
sources over from html [sic] to markdown format to allow ease
of editing.
Currently I am using just a generi
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #19 from Mike ---
Oh, and about atomic access... I agree that memory-mapped IO is shared, global
state, but I also agree that it is wasteful to wrap each and every access in
atomic accessors. A large amount of memory mapped I/O is do
On Wednesday, 11 June 2014 at 09:24:05 UTC, Iain Buclaw wrote:
Hi,
I'm in the process of switching over the gdcproject.org sources
over from html [sic] to markdown format to allow ease of
editing.
Currently I am using just a generic markdown script to generate
the static webpages (ie: Markd
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #18 from Mike ---
I should also add that the inline asm volatileGet/volatileSet workaround is
just that: a workaround. For the programmer to have to resort to these
techniques is an indication that the language is lacking. If I wan
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #17 from Mike ---
I hope we can all agree that volatile semantics are necessary for this kind of
programming regardless of whether it is implemented as an asm workaround,
compiler intrinsic functions, or a type qualifier.
I also hope
