On 07/17/2014 04:01 PM, Byron Heads wrote:
A Volatile(T) in stdlib seems to make a lot of sense, I am also wondering
if the implementation of shared should be done the same way (if it does
already then ignore), just use the compile to enforce shared and have it
rewrite it as Shared(T).
...
On 07/17/2014 05:58 PM, Andrei Alexandrescu wrote:
* volatile has been one of the most awkward parts of the C and C++
specifications. If we're to learn of anything about it, it's we must
stay away from it. It is extremely heavy for what it provides.
...
==
I think an approach
On 7/18/2014 11:06 AM, Timon Gehr wrote:
On 07/17/2014 05:58 PM, Andrei Alexandrescu wrote:
* volatile has been one of the most awkward parts of the C and C++
specifications. If we're to learn of anything about it, it's we must
stay away from it. It is extremely heavy for what it provides.
...
On 7/18/2014 10:53 AM, Timon Gehr wrote:
I've grepped the DMD source and currently 'shared' is a _bit flag_ set or not
set on some uint member field of the 'Type' class. I assume this is also the
main reason why adding new type qualifiers is a really unpleasant undertaking:
this is a highly
On 07/18/2014 08:37 PM, Walter Bright wrote:
On 7/18/2014 11:06 AM, Timon Gehr wrote:
On 07/17/2014 05:58 PM, Andrei Alexandrescu wrote:
* volatile has been one of the most awkward parts of the C and C++
specifications. If we're to learn of anything about it, it's we must
stay away from it.
On 7/18/2014 4:58 PM, Timon Gehr wrote:
On 07/18/2014 08:37 PM, Walter Bright wrote:
That doesn't change the heavy effort in the semantic front end
What does this mean in detail? Is it just about the unfortunate AST
representation chosen or are there more sources of heavy effort in the front
On 07/19/2014 02:07 AM, Walter Bright wrote:
On 7/18/2014 4:58 PM, Timon Gehr wrote:
On 07/18/2014 08:37 PM, Walter Bright wrote:
That doesn't change the heavy effort in the semantic front end
What does this mean in detail? Is it just about the unfortunate AST
representation chosen or are
On 7/18/2014 6:16 PM, Timon Gehr wrote:
On 07/19/2014 02:07 AM, Walter Bright wrote:
On 7/18/2014 4:58 PM, Timon Gehr wrote:
On 07/18/2014 08:37 PM, Walter Bright wrote:
That doesn't change the heavy effort in the semantic front end
What does this mean in detail? Is it just about the
On 7/16/2014 1:12 PM, Johannes Pfau wrote:
I'll take this as you pre-approve all the mentioned extensions?
* way to disable typeinfo for struct
Worth investigating. It'd probably be much more effective to work the linker
angle of removing items for which no references exist. Martin was
On 17 July 2014 07:09, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 7/16/2014 1:12 PM, Johannes Pfau wrote:
I'll take this as you pre-approve all the mentioned extensions?
* way to disable typeinfo for struct
Worth investigating. It'd probably be much more
On Wednesday, 16 July 2014 at 20:11:22 UTC, Johannes Pfau wrote:
I think it's kinda ridiculous that D embedded code will only be
usable
with strong optimization flags, but whatever.
Do you have numbers? Transitive volatility implies you planned to
do very complex things in embedded. If
On Wednesday, 16 July 2014 at 20:14:38 UTC, Johannes Pfau wrote:
* way to disable typeinfo for struct
* way to disable initializer
* force inlining
* (way to omit copy constructor function / force inline)
BTW, can't lto already remove this unused data? LDC inlines
simple initializers already,
On Wed, 16 Jul 2014 11:49:21 -0700, Walter Bright wrote:
I'll add that if it turns out we can't do a wrapper because of some
limitations/bugs in D's expressiveness, that is the problem with D we
need to fix, not adding another type modifier.
It all comes down to leverage. Making user
Iain Buclaw via Digitalmars-d wrote in message
news:mailman.4214.1405521071.2907.digitalmar...@puremagic.com...
No they don't. Intrinsics make things worse.
? At worst they're useless.
They are _trivial_ to implement for any of the compilers.
No they aren't, unless you are talking
On 7/15/14, 9:25 AM, Johannes Pfau wrote:
DIP62 describes how to solve this problem and make embedded programming
a first-class citizen in D:
http://wiki.dlang.org/DIP62
[snip]
The good:
This is a very crisply-written and comprehensive proposal. It could use
a little work (e.g. define the
On Thursday, 17 July 2014 at 15:58:05 UTC, Andrei Alexandrescu
wrote:
I think an approach based on functions peek/poke is a lot more
promising. D programs must define sequences of std calls
anyway, otherwise even the simplest programs that use
writeln(What's your name?) followed by a readln()
We had the volatile statement as a compiler barrier in D1. Why
not basically that instead of a type qualifier? We pretty much
need it back for atomics anyway.
On 7/17/14, 9:06 AM, John Colvin wrote:
On Thursday, 17 July 2014 at 15:58:05 UTC, Andrei Alexandrescu wrote:
I think an approach based on functions peek/poke is a lot more
promising. D programs must define sequences of std calls anyway,
otherwise even the simplest programs that use
On 17 July 2014 17:16, Sean Kelly via Digitalmars-d
digitalmars-d@puremagic.com wrote:
We had the volatile statement as a compiler barrier in D1. Why not basically
that instead of a type qualifier? We pretty much need it back for atomics
anyway.
I don't recall volatile statements ever working
On 7/17/14, 12:15 PM, Iain Buclaw via Digitalmars-d wrote:
On 17 July 2014 17:16, Sean Kelly via Digitalmars-d
digitalmars-d@puremagic.com wrote:
We had the volatile statement as a compiler barrier in D1. Why not basically
that instead of a type qualifier? We pretty much need it back for
On 7/17/2014 9:16 AM, Sean Kelly wrote:
We had the volatile statement as a compiler barrier in D1. Why not basically
that instead of a type qualifier? We pretty much need it back for atomics
anyway.
Volatile and atomic semantics are very different, are historically conflated and
confused,
Am Thu, 17 Jul 2014 11:43:04 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 7/17/14, 9:06 AM, John Colvin wrote:
On Thursday, 17 July 2014 at 15:58:05 UTC, Andrei Alexandrescu
wrote:
I think an approach based on functions peek/poke is a lot more
promising. D programs
On Thursday, 17 July 2014 at 19:31:25 UTC, Walter Bright wrote:
On 7/17/2014 9:16 AM, Sean Kelly wrote:
We had the volatile statement as a compiler barrier in D1. Why
not basically
that instead of a type qualifier? We pretty much need it back
for atomics anyway.
Volatile and atomic
Am Thu, 17 Jul 2014 08:05:33 +0100
schrieb Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com:
On 17 July 2014 07:09, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 7/16/2014 1:12 PM, Johannes Pfau wrote:
I'll take this as you pre-approve all the mentioned
On 17 July 2014 21:01, Johannes Pfau via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Am Thu, 17 Jul 2014 08:05:33 +0100
schrieb Iain Buclaw via Digitalmars-d digitalmars-d@puremagic.com:
On 17 July 2014 07:09, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On
On Thursday, 17 July 2014 at 19:56:23 UTC, Johannes Pfau wrote:
Am Thu, 17 Jul 2014 11:43:04 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
On 7/17/14, 9:06 AM, John Colvin wrote:
On Thursday, 17 July 2014 at 15:58:05 UTC, Andrei
Alexandrescu
wrote:
I think an approach
On Thursday, 17 July 2014 at 20:42:16 UTC, Iain Buclaw via
Digitalmars-d wrote:
Just mark them as extern. More important, we need a way to
build the
bodies of functions in other modules for cross-module inlining
(needed
for @forceinline to work correctly without getting 'function
body is
not
Johannes Pfau wrote in message news:lq51u4$21qb$1...@digitalmars.com...
But it's not only about frequency, it's also about convenience and
safety. How often is opDispatch actually used? The synchronized
statement? Nevertheless they are there, because someone thought these
use cases are
On 7/15/2014 9:29 PM, Brad Roberts via Digitalmars-d wrote:
I don't have any skin in this particular discussion, but it's worth pointing out
here that while it's cute that builtin's can be added, when they're not part of
the language definition, they're not really part of a portable solution.
On 15 July 2014 22:57, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 7/15/2014 2:17 PM, Johannes Pfau wrote:
Well as long as those priorities are clearly communicated. If you tell
me 'we don't care about embedded programming' then I'll shut up and move
back to C.
On 16 July 2014 07:12, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 7/15/2014 9:29 PM, Brad Roberts via Digitalmars-d wrote:
I don't have any skin in this particular discussion, but it's worth
pointing out
here that while it's cute that builtin's can be added, when
On 7/15/2014 10:15 PM, Johannes Pfau wrote:
Yes, I actually tried tested that simple implementation with gdc. With
aggressive optimizations the code inlines just fine and it'll generate
the same asm as an access to a volatile variable in C. But it's not
space-effecient: Even if it inlines, the
On 7/15/2014 9:30 PM, Mike wrote:
On Tuesday, 15 July 2014 at 19:48:23 UTC, Walter Bright wrote:
The one thing peek/poke doesn't offer is transitivity. C/C++ don't offer
volatile transitivity either. I'm not at all sure that anyone builds a data
structure in memory-mapped registers, so I'm not
On 7/15/2014 11:32 PM, Iain Buclaw via Digitalmars-d wrote:
On 16 July 2014 07:12, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 7/15/2014 9:29 PM, Brad Roberts via Digitalmars-d wrote:
I don't have any skin in this particular discussion, but it's worth
pointing out
On 7/15/2014 11:23 PM, Iain Buclaw via Digitalmars-d wrote:
GDC doesn't support it as compiler intrinsics.
I know.
Also, isn't inp/outp all x86-specific?
Yes. This is not an argument that x86 compilers shouldn't support them. After
all, D is supposed to be a systems programming language.
On Wednesday, 16 July 2014 at 05:17:56 UTC, Johannes Pfau wrote:
I think if we decide that Volatile!T is the solution I'd
probably hack
an attribute @TypeWrapper for gdc which simply recognized
Volatile!T
and does the right thing.
I'd recommend @fantom name, because not only type wrappers
Kagamin:
I'd recommend @fantom name, because not only type wrappers can
benefit from these optimizations. Should be also applicable to
functions and maybe modules.
This sounds like something fit for D too, not just gdc. You can
use it for std.typecons.Typedef too.
Bye,
bearophile
On 16 July 2014 08:08, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 7/15/2014 11:32 PM, Iain Buclaw via Digitalmars-d wrote:
On 16 July 2014 07:12, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 7/15/2014 9:29 PM, Brad Roberts via Digitalmars-d
Walter Bright:
struct VolatilePointerToUint {
private:
size_t ptr;
public:
this(size_t ptr) { this.ptr = ptr; }
uint read() { return peek(cast(uint*)ptr); }
void write(uint value) { poke(cast(uint*)ptr, value); }
}
You'd probably wish to flesh this out a bit more, but it's
Then we can have phantom functions for porting C macros instead
of templates :) (oh it's spelled with 'ph').
On Wednesday, 16 July 2014 at 05:17:56 UTC, Johannes Pfau wrote:
There's TypeInfo and there's the assert(this)
The optimizer should be able to eliminate this assert after
inlining as it knows it's not null. It should be looked into, why
the optimizer didn't remove it.
On 16 July 2014 08:16, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 7/15/2014 11:23 PM, Iain Buclaw via Digitalmars-d wrote:
GDC doesn't support it as compiler intrinsics.
I know.
Also, isn't inp/outp all x86-specific?
Yes. This is not an argument that x86
On 7/16/2014 1:35 AM, Iain Buclaw via Digitalmars-d wrote:
Which would you prefer?
The simplest, which is just to use a version declaration to select whatever
works for any particular compiler/CPU.
On Tuesday, 15 July 2014 at 21:28:24 UTC, Walter Bright wrote:
Peek/poke has a 40 year history of being used for MMIO, and
I've never heard of it being used for concurrency. I don't
think there's endemic confusion, quite unlike volatile.
There is a huge confusion about volatile in the native
Am Wed, 16 Jul 2014 15:59:46 +1000
schrieb Daniel Murphy yebbliesnos...@gmail.com:
The problem is not 'this feature is too complex', the problems is
that it's more complex than necessary.
So what's necessary in this specific case?
Am Tue, 15 Jul 2014 23:38:21 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 7/15/2014 10:15 PM, Johannes Pfau wrote:
Yes, I actually tried tested that simple implementation with gdc.
With aggressive optimizations the code inlines just fine and it'll
generate the same asm as an
Am Tue, 15 Jul 2014 19:44:51 +0200
schrieb Artur Skawina via Digitalmars-d digitalmars-d@puremagic.com:
it originally and also the gdc ml discussion that followed. I have
not seen any good argument for introducing a volatile type qualifier.
Could you show one (concrete) example where using
On Wednesday, 16 July 2014 at 13:04:37 UTC, Johannes Pfau wrote:
I experimented a little more with Volatile!T and I don't think
you can make this example work:
struct Timer
{
uint control;
uint data;
}
enum timerA = (Volatile!Timer)* = cast()0xDEADBEAF;
timerA.control |= 0b1;
How
On Wednesday, 16 July 2014 at 13:51:49 UTC, Kagamin wrote:
On Wednesday, 16 July 2014 at 13:04:37 UTC, Johannes Pfau wrote:
I experimented a little more with Volatile!T and I don't think
you can
make this example work:
struct Timer
{
uint control;
uint data;
}
enum timerA =
On Wednesday, 16 July 2014 at 13:04:37 UTC, Johannes Pfau wrote:
I experimented a little more with Volatile!T and I don't think
you can
make this example work:
struct Timer
{
uint control;
uint data;
}
enum timerA = (Volatile!Timer)* = cast()0xDEADBEAF;
timerA.control |= 0b1;
The
Johannes Pfau wrote in message news:lq5pv1$2nfb$1...@digitalmars.com...
The problem is not 'this feature is too complex', the problems is
that it's more complex than necessary.
So what's necessary in this specific case?
Use intrinsics with a nice template wrapper. They get inlined, the
On 16 July 2014 15:14, Daniel Murphy via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Johannes Pfau wrote in message news:lq5pv1$2nfb$1...@digitalmars.com...
The problem is not 'this feature is too complex', the problems is
that it's more complex than necessary.
So what's necessary
On 7/16/2014 7:14 AM, Daniel Murphy wrote:
Intrinsics get us away from our current 'there is no portable way to do this'
situation. They are _trivial_ to implement for any of the compilers. I have
complete faith that it is possible to make a performant wrapper for both the
single-register
On 7/16/2014 7:31 AM, Iain Buclaw via Digitalmars-d wrote:
They are _trivial_ to implement for any of the compilers.
No they aren't, unless you are talking specifically about volatile.,
in which case, that depends...
If the compiler back end doesn't support volatile, then it's a problem
On 16 July 2014 19:58, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 7/16/2014 7:31 AM, Iain Buclaw via Digitalmars-d wrote:
They are _trivial_ to implement for any of the compilers.
No they aren't, unless you are talking specifically about volatile.,
in which case,
On 16 July 2014 20:03, Iain Buclaw ibuc...@gdcproject.org wrote:
On 16 July 2014 19:58, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 7/16/2014 7:31 AM, Iain Buclaw via Digitalmars-d wrote:
They are _trivial_ to implement for any of the compilers.
No they aren't,
On 7/16/2014 5:59 AM, Johannes Pfau wrote:
And how do you implement this with a wrapper? This is common in C/C++:
struct Timer
{
uint control;
uint data;
}
enum timerA = (Volatile!Timer)* = cast()oxDEADBEAF;
timerA.control |= 0b1;
auto timerA = VolatileStruct!Timer(0xDEADBEAF);
On 7/16/2014 12:10 PM, Iain Buclaw via Digitalmars-d wrote:
By the way, it's 'so-called' bugs like this that make we want to
remove any notion of volatile from shared.
Right.
On 07/16/14 15:02, Johannes Pfau via Digitalmars-d wrote:
Am Tue, 15 Jul 2014 19:44:51 +0200
schrieb Artur Skawina via Digitalmars-d digitalmars-d@puremagic.com:
Could you show one (concrete) example where using 'volatile' is better
than my approach?
I experimented a little more with
Am Wed, 16 Jul 2014 21:59:57 +0200
schrieb Artur Skawina via Digitalmars-d digitalmars-d@puremagic.com:
On 07/16/14 15:02, Johannes Pfau via Digitalmars-d wrote:
Am Tue, 15 Jul 2014 19:44:51 +0200
schrieb Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com:
Could you show one
Am Wed, 16 Jul 2014 11:49:21 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 7/16/2014 7:14 AM, Daniel Murphy wrote:
Intrinsics get us away from our current 'there is no portable way
to do this' situation. They are _trivial_ to implement for any of
the compilers. I have
On 07/16/14 22:09, Johannes Pfau via Digitalmars-d wrote:
Well I guess this is already decided anyway.
Well, peek/poke is not the right solution either...
I think it's kinda ridiculous that D embedded code will only be usable
with strong optimization flags, but whatever. Maybe it works better
You may have seen Mike's talk about D on embedded systems and were
surprised about Iain's comment that using 'shared' as a replacement for
'volatile' is actually only possible because of a bug in gdc.
DIP62 describes how to solve this problem and make embedded programming
a first-class citizen in
On 07/15/14 18:25, Johannes Pfau via Digitalmars-d wrote:
here again: We need _first-class_ support for embedded programming in
D. Workarounds might be available (peek/poke, inline asm) but it will
be obvious to most C programmers that C has got the better solution
with the volatile
Artur Skawina:
You can already express
all the described volatile semantics in GDC's D dialect, in a
completely portable way and without using a single asm
instruction.
What's GDC syntax?
Bye,
bearophile
Am Tue, 15 Jul 2014 17:07:26 +
schrieb bearophile bearophileh...@lycos.com:
Artur Skawina:
You can already express
all the described volatile semantics in GDC's D dialect, in a
completely portable way and without using a single asm
instruction.
What's GDC syntax?
Bye,
Am Tue, 15 Jul 2014 19:03:52 +0200
schrieb Artur Skawina via Digitalmars-d digitalmars-d@puremagic.com:
Compiler barriers are not workarounds. volatile is not a better
solution. It's used in C only because it's defined and reasonably
portable; barriers are a language extension, hence dialect
On 15 July 2014 17:25, Johannes Pfau via Digitalmars-d
digitalmars-d@puremagic.com wrote:
You may have seen Mike's talk about D on embedded systems and were
surprised about Iain's comment that using 'shared' as a replacement for
'volatile' is actually only possible because of a bug in gdc.
On 07/15/14 19:07, bearophile via Digitalmars-d wrote:
Artur Skawina:
You can already express
all the described volatile semantics in GDC's D dialect, in a
completely portable way and without using a single asm instruction.
What's GDC syntax?
Some examples:
Johannes Pfau wrote in message news:lq3nf4$rbp$1...@digitalmars.com...
Did you even read the section that explains why volatility is a property
of the memory address and not of the access (4.2.3)? What's your
response to that?
This is true, and it's the ideal I guess, but I'm not sure that
On 07/15/14 19:11, Johannes Pfau via Digitalmars-d wrote:
Am Tue, 15 Jul 2014 19:03:52 +0200
schrieb Artur Skawina via Digitalmars-d digitalmars-d@puremagic.com:
Compiler barriers are not workarounds. volatile is not a better
solution. It's used in C only because it's defined and reasonably
On Tuesday, 15 July 2014 at 17:13:09 UTC, Johannes Pfau wrote:
Why do shared variables have the privilege to prevent accessing
shared
memory in inappropriate ways but it's fine to place the burden
of
checking that all accesses to volatile memory are backed by
compiler
barriers to the user?
Am Tue, 15 Jul 2014 17:42:47 +
schrieb Kagamin s...@here.lot:
On Tuesday, 15 July 2014 at 17:13:09 UTC, Johannes Pfau wrote:
Why do shared variables have the privilege to prevent accessing
shared
memory in inappropriate ways but it's fine to place the burden
of
checking that all
On Tuesday, 15 July 2014 at 17:50:13 UTC, Johannes Pfau wrote:
And that's why I say first class support: We don't have
shared!(T) we
have shared T. And volatile should get it's own qualifier as
well.
Also some things will just not work with Volatile!T, for example
volatile/nonvolatile member
On Tuesday, 15 July 2014 at 17:50:13 UTC, Johannes Pfau wrote:
Then we have a templated struct. Which generates TypeInfo for
every
instance. Which might generate an Initializer for every
instance and
it might generate extended debug info for every instance.
These are exactly the kind of
Am Tue, 15 Jul 2014 19:44:51 +0200
schrieb Artur Skawina via Digitalmars-d digitalmars-d@puremagic.com:
On 07/15/14 19:11, Johannes Pfau via Digitalmars-d wrote:
Am Tue, 15 Jul 2014 19:03:52 +0200
schrieb Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com:
Compiler barriers
Am Wed, 16 Jul 2014 03:33:35 +1000
schrieb Daniel Murphy yebbliesnos...@gmail.com:
Johannes Pfau wrote in message news:lq3nf4$rbp$1...@digitalmars.com...
Did you even read the section that explains why volatility is a
property of the memory address and not of the access (4.2.3)?
What's
On Tuesday, 15 July 2014 at 18:30:11 UTC, Johannes Pfau wrote:
No, this doesn't work with Volatile!:
struct A
{
private int _val;
int read(){ return val+val };
int read(bool volatile)() { auto tmp = val; return tmp*tmp;
};
}
struct A
{
private int _val;
int read(bool
Am Tue, 15 Jul 2014 18:13:26 +
schrieb Meta jared...@gmail.com:
Also some things will just not work with Volatile!T, for example
volatile/nonvolatile member function overloading.
Functions can take Volatile!T, of course, and you can always have
set/volatileSet. You might even be
On 07/15/14 20:20, Johannes Pfau via Digitalmars-d wrote:
(For example, in gcc even a force inline attribute does not inline if
-finline is not used. I don't consider that acceptable for this kind of
code. So we might have to special case Volatile!T even more in the
compiler, to really always
On 15 July 2014 19:38, Meta via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Tuesday, 15 July 2014 at 18:30:11 UTC, Johannes Pfau wrote:
No, this doesn't work with Volatile!:
struct A
{
private int _val;
int read(){ return val+val };
int read(bool volatile)() { auto tmp
On Tuesday, 15 July 2014 at 19:23:36 UTC, Iain Buclaw via
Digitalmars-d wrote:
Worse, there's no code because the compiler optimises
everything away!
I was assuming you'd do something in the static if (volatile)
section to stop it from doing that. I know very little when it
comes to these
On 7/15/2014 9:25 AM, Johannes Pfau wrote:
DIP62 describes how to solve this problem and make embedded programming
a first-class citizen in D:
http://wiki.dlang.org/DIP62
This is a particularly well-written DIP, thank you and the other contributors
to it.
* Although it's explained in the
Am Tue, 15 Jul 2014 12:48:21 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 7/15/2014 9:25 AM, Johannes Pfau wrote:
DIP62 describes how to solve this problem and make embedded
programming a first-class citizen in D:
http://wiki.dlang.org/DIP62
This is a particularly
Johannes Pfau:
Well as described in the DIP it works just like shared from an
implementation point of view, so I doesn't add much complexity
in the compiler / type system.
I am reading blogs about compiler bugs, and I see that the
implementation of volatile is the buggiest part of GCC/Clang
On 15 July 2014 22:07, bearophile via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Johannes Pfau:
Well as described in the DIP it works just like shared from an
implementation point of view, so I doesn't add much complexity in the
compiler / type system.
I am reading blogs about
On 15 July 2014 22:17, Iain Buclaw ibuc...@gdcproject.org wrote:
On 15 July 2014 22:07, bearophile via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Johannes Pfau:
Well as described in the DIP it works just like shared from an
implementation point of view, so I doesn't add much
Johannes Pfau:
//In runtime:
enum int* SOME_REG = 0x;
//In user code
peek(SOME_REG);
poke(SOME_REG);
*SOME_REG = 1; //Oops, forgot poke! This is not acceptable
Perhaps this syntax:
volatile enum int* SOME_REG = 0x;
Could turn this in a syntax error (only peek/poke are allowed to
Am Tue, 15 Jul 2014 21:07:21 +
schrieb bearophile bearophileh...@lycos.com:
Johannes Pfau:
Well as described in the DIP it works just like shared from an
implementation point of view, so I doesn't add much complexity
in the compiler / type system.
I am reading blogs about
Am Tue, 15 Jul 2014 21:16:20 +
schrieb bearophile bearophileh...@lycos.com:
Johannes Pfau:
//In runtime:
enum int* SOME_REG = 0x;
//In user code
peek(SOME_REG);
poke(SOME_REG);
*SOME_REG = 1; //Oops, forgot poke! This is not acceptable
Perhaps this syntax:
volatile
Iain Buclaw:
The use of volatile can be buggy in C because there is no other
safe way to do inter-thread communication.
C11 offers means much better than volatile for multi thread
programming:
http://en.wikipedia.org/wiki/C11_%28C_standard_revision%29#Changes_from_C99
So your saying that
On 7/15/2014 1:43 PM, Johannes Pfau wrote:
1. Volatile has caused a major increase in the complexity of the C++
type system
- a complexity far out of proportion to the value it provides. It
would have a similar complex and pervasive effect on the D type
system.
Well as described in the DIP it
Johannes Pfau:
And how do you think peek/poke are easier to implement in this
regard?
Let's ask Walter.
Well as long as those priorities are clearly communicated.
Most of the design of D is not geared toward embedded computing.
It could be adapted and improved for those purposes, but
On 7/15/2014 2:17 PM, Johannes Pfau wrote:
Well as long as those priorities are clearly communicated. If you tell
me 'we don't care about embedded programming' then I'll shut up and move
back to C.
Rest assured we definitely do care about embedded systems programming.
But 'D is a systems
On 7/15/2014 2:28 PM, bearophile wrote:
Johannes Pfau:
And how do you think peek/poke are easier to implement in this regard?
Let's ask Walter.
peek/poke should be implemented as compiler intrinsics that are then mapped onto
whatever the backend does best for 'volatile' accesses.
On 7/15/2014 2:22 PM, Johannes Pfau wrote:
The DIP may seem complicated cause it considers overloading,
transitivity and similar stuff. In practice almost nobody will use
these features. But if I had not specified them Walters first question
would have been How does it interact with overloading
On Tuesday, 15 July 2014 at 20:45:20 UTC, Johannes Pfau wrote:
Am Tue, 15 Jul 2014 12:48:21 -0700
schrieb Walter Bright newshou...@digitalmars.com:
3. if you really hate peek/poke calls appearing in the code,
you can
use UFCS to make them look like variables
But you cant do REGISTER.peek()
On Tuesday, 15 July 2014 at 21:28:24 UTC, Walter Bright wrote:
I don't think this is the right argument. It isn't about
embedded systems should be acknowledged with a qualifier. I see
it as about how often does MMIO logic appear in an actual
embedded program? In the embedded systems I've
On 7/15/2014 4:52 PM, Steve Sobel wrote:
So in my opinion, and without prescribing the exact solution,
volatility is an important enough concept in embedded to merit a
standard solution that can be mechanically verified.
There is another way. The peek() and poke() functions are primitive. You
On Tuesday, 15 July 2014 at 21:57:56 UTC, Walter Bright wrote:
Rest assured we definitely do care about embedded systems
programming.
That's most encouraging to read! D has a lot of potential for
embedded programming, we just need to be thrown a few bones.
It isn't about whether we want to
1 - 100 of 107 matches
Mail list logo
