On Sunday, 5 April 2015 at 15:58:17 UTC, Iain Buclaw wrote:
--- Comment #24 from Iain Buclaw ---
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-o
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #24 from Iain Buclaw ---
(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 v
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
Jens Bauer changed:
What|Removed |Added
CC||jens-bugzi...@gpio.dk
--- Comment #23 from
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
Johannes Pfau changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
Johannes Pfau changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|ibuc...@gdcp
Am Wed, 16 Jul 2014 14:41:42 +0100
schrieb "Iain Buclaw via D.gnu" :
> On 16 July 2014 14:10, Johannes Pfau via D.gnu
> wrote:
> > Am Wed, 16 Jul 2014 05:53:30 +
> > schrieb "Timo Sintonen" :
> >
> >> On Tuesday, 24 June 2014 at 14:14:18 UTC, Johannes Pfau wrote:
> >>
> >> > I think we should
On 16 July 2014 14:10, Johannes Pfau via D.gnu wrote:
> Am Wed, 16 Jul 2014 05:53:30 +
> schrieb "Timo Sintonen" :
>
>> 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 g
Am Wed, 16 Jul 2014 05:53:30 +
schrieb "Timo Sintonen" :
> 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 co
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 t
On 30 Jun 2014 23:20, "bearophile via D.gnu" wrote:
>
> Iain Buclaw:
>
>> http://bugzilla.gdcproject.org/show_bug.cgi?id=126
>
>
> The D1 deprecation warning to replace volatile with synchronized:
>
>
https://github.com/D-Programming-Language/dmd/commit/c8d580aea687f16b56ff4ce935f618b41a74c6e7
>
>
Iain Buclaw:
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
The D1 deprecation warning to replace volatile with synchronized:
https://github.com/D-Programming-Language/dmd/commit/c8d580aea687f16b56ff4ce935f618b41a74c6e7
Bye,
bearophile
On Tuesday, 24 June 2014 at 14:14:18 UTC, Johannes Pfau wrote:
Am Tue, 24 Jun 2014 10:46:11 +
schrieb "Timo Sintonen" :
To keep this thread going, I had a quick look at the reference
material of the dip and picked some thoughts.
In some languages volatile has a stronger meaning, like
gua
Am Tue, 24 Jun 2014 10:46:11 +
schrieb "Timo Sintonen" :
> To keep this thread going, I had a quick look at the reference
> material of the dip and picked some thoughts.
>
> In some languages volatile has a stronger meaning, like
> guaranteeing an atomic access. In some languages it may not
On 24 June 2014 11:46, Timo Sintonen via D.gnu wrote:
>
> While writing this it just popped to my mind: if volatile is not good,
> could we reuse the 'system' word? Then it would be clear that this is for
> accessing system resources and not for application level.
>
> There seems not to be much d
To keep this thread going, I had a quick look at the reference
material of the dip and picked some thoughts.
In some languages volatile has a stronger meaning, like
guaranteeing an atomic access. In some languages it may not
guarantee anything.
In this proposal volatile is only for optimizat
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
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
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
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #16 from Martin Nowak ---
(In reply to Johannes Pfau from comment #15)
> The classical hello world for these devices is usually blinking a LED
> (http://www.micahcarrick.com/tutorials/avr-microcontroller-tutorial/getting-
> started.ht
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #15 from Johannes Pfau ---
> Didn't knew about this proposal
It's not yet been announced/discussed, though I'll probably start a discussion
on the newsgroup this week.
> but it's flawed IMO, because
> read-modify-write operations mi
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #14 from Martin Nowak ---
Bit-bending I/O is a counter-example against the "no performance needed"
argument, but I still think this can be achieved easily enough with the
existing tools, i.e. by inlining the asm code in your hot loop
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
Martin Nowak changed:
What|Removed |Added
CC||c...@dawg.eu
--- Comment #13 from Martin
Am Mon, 02 Jun 2014 17:51:39 +
schrieb "Marc Schütz" :
> On Monday, 2 June 2014 at 17:27:52 UTC, Johannes Pfau wrote:
> > And of course without a type qualifier there can't be
> > transitivity. The
> > programmer always has to be careful to access struct members,
> > array members,
> > and o
On Monday, 2 June 2014 at 17:27:52 UTC, Johannes Pfau wrote:
And of course without a type qualifier there can't be
transitivity. The
programmer always has to be careful to access struct members,
array members,
and other types 'connected' via indirection with peek/poke.
I too think that a) vol
Am Sun, 01 Jun 2014 15:37:04 +
schrieb "Timo Sintonen" :
> I did not yet read the dip but here are some of my thoughts:
>
Thanks for joining this discussion, your input is very appreciated.
> At the old days peripherals were simple. An uart might have a
> control register, a status registe
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #12 from Johannes Pfau ---
> I've created a "design discussion" around this debate on the D wiki:
> http://wiki.dlang.org/Language_design_discussions#volatile
Thanks, that's very useful. I did not even remember that we already had
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #11 from Mike ---
Ok, clearly I have not fully understood shared semantics.
> In future, the compiler would memoize the loop and go straight for the
> assignment.
>
> mov$12, _D4test4globi(%rip)
That would be very bad for my m
I did not yet read the dip but here are some of my thoughts:
At the old days peripherals were simple. An uart might have a
control register, a status register and a data register, 8 bit
each. It just did not matter how they were accessed. Now a
peripheral like usb or ethernet may have tens of
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #10 from Iain Buclaw ---
(In reply to Johannes Pfau from comment #9)
> @Mike: AFAIK shared has some additional requirements which are not necessary
> for volatile:
>
> 1.) Atomic access: Accessing shared variables must always use ato
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #9 from Johannes Pfau ---
@Mike: AFAIK shared has some additional requirements which are not necessary
for volatile:
1.) Atomic access: Accessing shared variables must always use atomic access
(This is not yet enforced, but see
https
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #8 from Mike ---
But regardless of the solution, it would be nice if it were a front-end feature
implemented by all compilers.
--
You are receiving this mail because:
You are watching all bug changes.
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
Mike changed:
What|Removed |Added
CC||slavo5...@yahoo.com
--- Comment #7 from Mike ---
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #6 from Iain Buclaw ---
(In reply to Johannes Pfau from comment #5)
> Oh, and back to topic:
>
> > I am quite open to solutions, other than I don't think 'volatile' as a
> > keyword > would be something reintroduced to the language
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #5 from Johannes Pfau ---
Oh, and back to topic:
> I am quite open to solutions, other than I don't think 'volatile' as a
> keyword > would be something reintroduced to the language am afaid.
Yes, that's what I fear as well. But th
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #4 from Johannes Pfau ---
Yes, I was eagerly waiting for that talk. Unfortunately the most interesting
talks are the last ones on each day and I couldn't watch these live because of
timezone stuff. I'll watch these as soon as recordin
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #3 from Iain Buclaw ---
Yes this has been raised at DConf.
Michael gave a good talk on Bare Metal programming, and mentioned that he's
relying on the use of shared currently meaning volatile to do a lot of low
level work in D, but wa
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
Johannes Pfau changed:
What|Removed |Added
CC||johannesp...@gmail.com
--- Comment #2 fr
http://bugzilla.gdcproject.org/show_bug.cgi?id=126
--- Comment #1 from Iain Buclaw ---
peek() and poke() intrinsics that are guaranteed to be volatile accessors are
also on the table.
--
You are receiving this mail because:
You are watching all bug changes.
39 matches
Mail list logo
