On Thursday, 24 October 2013 at 19:11:03 UTC, Walter Bright wrote:
On 10/24/2013 11:33 AM, eles wrote:
On Thursday, 24 October 2013 at 17:02:51 UTC, Walter Bright
wrote:
On 10/24/2013 4:18 AM, eles wrote:
On Thursday, 24 October 2013 at 06:48:07 UTC, Walter Bright
wrote:
On 10/23/2013 11:19 PM, Mike wrote:
Like I said, nobody (on the standards committees) could agree
on exactly what
that meant.
The standard committees might not agree, but there is somebody
out there that
really knows very accurately what that should mean: that
somebody is the
hardware itself.
Just imagine the best hardware example that you have at hand:
the microprocessor
that you are programming for.
It writes on the bus, there is a short delay before the
signals are guaranteed
to reach the correct levels, then reads the memory data and so
on.
You cannot read the data before the delay passes. You cannot
say "well, I could
postpone the writing on the address on the bus, let's read the
memory location
first" -- or you would read garbage. Or you cannot say: well,
first I will
execute the program without a processor then, when the user is
already pissed
off, I would finally execute all those instructions at once.
Too bad that the
computer is already flying through the window at that time.
You command that processor from the compiler. Now, the thing
that's needed is to
give a way to do the same (ie commanding a hardware) from the
program compiled
by the compiler.
The trouble with that is since the standards people cannot
agree on what volatile means, you're working with a compiler
that has non-standard behavior. This is not portable and not
reliable.
There should be some way, in the D language, to tell the compiler
"Do exactly what I say here, and don't try to be clever about
it" without introducing unnecessary (and unfortunate) overhead.
It doesn't have to be /volatile/.
/shared/ may be the solution here, but based on a comment by Iain
Buclaw
(http://forum.dlang.org/post/mailman.2454.1382619958.1719.digitalmar...@puremagic.com)
it seems there could be some disagreement on what this means to
compiler implementers. I don't see why "shared" could not only
mean "shared by more than one thread/cpu", but also "shared by
external hardware peripherals".
Maybe /shared/'s definition needs to be further defined to ensure
all compilers implement it the same way, and be unambiguous
enough to provide a solution to this /volatile/ debate.
Using peek and poke functions is, well, nah... Better methods
exist. Using inline assembly is a reasonable alternative, as is
linking to an external C library, but why use D then? Is
low-level/embedded software development a design goal of the D
language?
