On Tuesday, 24 June 2014 at 14:14:18 UTC, Johannes Pfau wrote:

> I think we should at least try to bring this to the main newsgroup,

I told you this is not going to work. The decision seems to be made even when the conversion is still going on. Lets just make this into gdc so we can continue the real work. When this is ready and working, we may try again.

Unfortunately I am not skilled enough to implement this into the compiler so I have to ask somebody else to do it. I will test it as soon it is possible.

This has even more importance now because I have understood that dmd will disallow read-modify-write access to shared variables. I hope this feature is not brought to gdc before volatile is working.

Am Wed, 16 Jul 2014 05:53:30 +0000
schrieb "Timo Sintonen" <t.sintonen@luukku.com>:

> On Tuesday, 24 June 2014 at 14:14:18 UTC, Johannes Pfau wrote:
> 
> > I think we should at least try to bring this to the main newsgroup,
> 
> I told you this is not going to work. The decision seems to be made even when the conversion is still going on. Lets just make this into gdc so we can continue the real work. When this is ready and working, we may try again.
> 
> Unfortunately I am not skilled enough to implement this into the compiler so I have to ask somebody else to do it. I will test it as soon it is possible.
> 
> This has even more importance now because I have understood that dmd will disallow read-modify-write access to shared variables. I hope this feature is not brought to gdc before volatile is working.
> 

I didn't have any high expectations, nevertheless we had to try.

Well I could implement the DIP for GDC, but this is against the vision of a shared frontend. In the end Iain has to decide what to do.

I'm not sure if I'd implement Volatile!T though. It's probably lots of work and there's no guarantee it'll work at all in the end. The more I think about it the more corner cases come to mind which all need to be worked around.

Keeping only peek/poke as Walter suggests of course also has drawbacks. peek/poke plus Mike's wrapper is probably the best we'll get from DMD.

Btw: @Iain if we implement these peek/poke things I think
asm{"" : : :"memory";} is not good enough. At least it's being removed
in some tests and according to some sources it only affect operations
on volatile variables... So we'd have to implement peek/poke on top of
C/GCC volatile.

On 16 July 2014 14:10, Johannes Pfau via D.gnu <d.gnu@puremagic.com> wrote:
> Am Wed, 16 Jul 2014 05:53:30 +0000
> schrieb "Timo Sintonen" <t.sintonen@luukku.com>:
>
>> On Tuesday, 24 June 2014 at 14:14:18 UTC, Johannes Pfau wrote:
>>
>> > I think we should at least try to bring this to the main newsgroup,
>>
>> I told you this is not going to work. The decision seems to be made even when the conversion is still going on. Lets just make this into gdc so we can continue the real work. When this is ready and working, we may try again.
>>
>> Unfortunately I am not skilled enough to implement this into the compiler so I have to ask somebody else to do it. I will test it as soon it is possible.
>>
>> This has even more importance now because I have understood that dmd will disallow read-modify-write access to shared variables. I hope this feature is not brought to gdc before volatile is working.
>>
>
> I didn't have any high expectations, nevertheless we had to try.
>
> Well I could implement the DIP for GDC, but this is against the vision of a shared frontend. In the end Iain has to decide what to do.
>
> I'm not sure if I'd implement Volatile!T though. It's probably lots of work and there's no guarantee it'll work at all in the end. The more I think about it the more corner cases come to mind which all need to be worked around.
>
> Keeping only peek/poke as Walter suggests of course also has drawbacks. peek/poke plus Mike's wrapper is probably the best we'll get from DMD.
>
> Btw: @Iain if we implement these peek/poke things I think
> asm{"" : : :"memory";} is not good enough. At least it's being removed
> in some tests and according to some sources it only affect operations
> on volatile variables... So we'd have to implement peek/poke on top of
> C/GCC volatile.

Wouldn't a reinterpret cast (VIEW_CONVERT_EXPR) to volatile be enough?

Something akin to:

T peek(T var) { return *(volatile T*)&var; }
T poke(T var, T val) { return *(volatile T*)&var = *(volatile T*)&val; }

Am Wed, 16 Jul 2014 14:41:42 +0100
schrieb "Iain Buclaw via D.gnu" <d.gnu@puremagic.com>:

> On 16 July 2014 14:10, Johannes Pfau via D.gnu <d.gnu@puremagic.com> wrote:
> > Am Wed, 16 Jul 2014 05:53:30 +0000
> > schrieb "Timo Sintonen" <t.sintonen@luukku.com>:
> >
> >> On Tuesday, 24 June 2014 at 14:14:18 UTC, Johannes Pfau wrote:
> >>
> >> > I think we should at least try to bring this to the main newsgroup,
> >>
> >> I told you this is not going to work. The decision seems to be made even when the conversion is still going on. Lets just make this into gdc so we can continue the real work. When this is ready and working, we may try again.
> >>
> >> Unfortunately I am not skilled enough to implement this into the compiler so I have to ask somebody else to do it. I will test it as soon it is possible.
> >>
> >> This has even more importance now because I have understood that dmd will disallow read-modify-write access to shared variables. I hope this feature is not brought to gdc before volatile is working.
> >>
> >
> > I didn't have any high expectations, nevertheless we had to try.
> >
> > Well I could implement the DIP for GDC, but this is against the vision of a shared frontend. In the end Iain has to decide what to do.
> >
> > I'm not sure if I'd implement Volatile!T though. It's probably lots of work and there's no guarantee it'll work at all in the end. The more I think about it the more corner cases come to mind which all need to be worked around.
> >
> > Keeping only peek/poke as Walter suggests of course also has drawbacks. peek/poke plus Mike's wrapper is probably the best we'll get from DMD.
> >
> > Btw: @Iain if we implement these peek/poke things I think
> > asm{"" : : :"memory";} is not good enough. At least it's being
> > removed in some tests and according to some sources it only affect
> > operations on volatile variables... So we'd have to implement
> > peek/poke on top of C/GCC volatile.
> 
> Wouldn't a reinterpret cast (VIEW_CONVERT_EXPR) to volatile be enough?
> 
> Something akin to:
> 
> T peek(T var) { return *(volatile T*)&var; }
> T poke(T var, T val) { return *(volatile T*)&var = *(volatile
> T*)&val; }

Yes I guess this should work. I just meant that a library solution with compiler barriers would probably not work.

http://bugzilla.gdcproject.org/show_bug.cgi?id=126

Johannes Pfau <johannespfau@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|ibuclaw@gdcproject.org      |johannespfau@gmail.com

--- Comment #21 from Johannes Pfau <johannespfau@gmail.com> ---
I've implemented __builtin_volatile_load/store in https://github.com/D-Programming-GDC/GDC/pull/82

with a DMD compatible API. (so volatileLoad/Store in core.bitop can be a simple
alias AFAICS)

I tested this and it should work and produce efficient code, but some feedback would be appreciated :-)

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=126

Johannes Pfau <johannespfau@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #22 from Johannes Pfau <johannespfau@gmail.com> ---
The volatileLoad/Store intrinsics will have to suffice.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=126

Jens Bauer <jens-bugzilla@gpio.dk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jens-bugzilla@gpio.dk

--- Comment #23 from Jens Bauer <jens-bugzilla@gpio.dk> ---
(In reply to Johannes Pfau from comment #22)
> The volatileLoad/Store intrinsics will have to suffice.

Are these guaranteed to be in the specified order for volatileLoad/Store, assuming a, b, c and d are different memory locations:

  read a
  write b
  read c
  read d

-Or would the compiler be able to mess up the order ?
I believe it's important to be able to keep the order exactly, so that you can
transfer data using several ports.

Simple (pseudo-code) example: SWD protocol

  SWDIO_DIR = 0;   /* data direction = input */
  SWCLK = 0;       /* clock pin low */
  i = SWDIO;       /* read data */
  SWCLK = 1;       /* clock pin high */
  SWDIO_DIR = 1;   /* data direction = output */
  SWDIO = o;       /* write bit 'o' */
  SWCLK = 0;       /* clock pin low */
  cast(void)SWDIO; /* read value but throw it away. (this delay is required) */
  SWCLK = 1;       /* clock pin high */

... A much more advanced example would be to have multiple clock pins and multiple ports where we read/write many bits on each port.

-- 
You are receiving this mail because:
You are watching all bug changes.

http://bugzilla.gdcproject.org/show_bug.cgi?id=126

--- Comment #24 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to Jens Bauer from comment #23)
> (In reply to Johannes Pfau from comment #22)
> > The volatileLoad/Store intrinsics will have to suffice.
> 
> Are these guaranteed to be in the specified order for volatileLoad/Store, assuming a, b, c and d are different memory locations:
> 
>   read a
>   write b
>   read c
>   read d
> 
> -Or would the compiler be able to mess up the order ?

Compiler reordering should never mess up order of program logic to variables/objects where changes are considered 'observable' (eg, on shared data).  Most re-ordering/memoization happens on 'non-observable' data such as local variables, thread-local storage.

However, that certainly doesn't stop certain C-like behaviours from occuring in the optimiser.  Such include crash-inducing operations like divide by zero may be pushed forward to occur before volatile load/reads or actions with side-effects.

-- 
You are receiving this mail because:
You are watching all bug changes.

On Sunday, 5 April 2015 at 15:58:17 UTC, Iain Buclaw wrote:
> --- Comment #24 from Iain Buclaw <ibuclaw@gdcproject.org> ---
> Compiler reordering should never mess up order of program logic to variables/objects where changes are considered 'observable' (eg, on shared data).  Most re-ordering/memoization happens on 'non-observable' data such as local variables, thread-local storage.
>
> However, that certainly doesn't stop certain C-like behaviours from occuring in the optimiser.  Such include crash-inducing
> operations like divide by zero may be pushed forward to occur
> before volatile load/reads or actions with side-effects.

I find these to be very good technical details.
If there's any documentation on volatileLoad and volatileStore, I think the above should be added.