I've scanned the postings on this subject and tried to follow them.  I do appreciate the need for direct hardware access.  Thanks Walter for taking time with this subject and putting volatile into D.

Someone should take the D compiler and attempt to port one of the free embedded operating systems to D.  It would have to be customized hardware, not something like PC/104 which is just a PC in a different mechanical form factor.  Of course it would have to run an Intel CPU for the time being.

http://rome.sourceforge.net/

Many others exist.

Mark

"Robert W. Cunningham" <FlyPG@users.sourceforge.net> wrote in message news:3D87F4A4.D37093A8@users.sourceforge.net...
> Walter wrote:
>
> > "Robert W. Cunningham" <FlyPG@users.sourceforge.net> wrote in message news:3D8571DA.5BAE5977@users.sourceforge.net...
> > > So, I do agree that compiler caching isn't much of an issue.  But that
is
> > only
> > > a small part of what "volatile" must handle.
> >
> > How should code be generated differently?
>
> I don't keep this stuff in my head!  Back in the day, I'd go to the
processor
> manual and look it up.  And I haven't used an x86 processor on an embedded project since the 8086.  But I do know that "volatile" works just fine on
an
> x86!

All it does is prevent caching of loads in a register, and prevent elimination of dead stores.


> > p.get() is only 5 characters more, and no extra code is actually
generated.
> But how much more code is generated?  More importantly, how many times
longer
> does it take to execute that code compared to "*p"?

No difference at all.

> If there is absolutely zero difference (it is one or two instructions),
then
> you and I are describing identical functionality, only from different perspectives.

Yes.

> But if there is any difference, then your version of volatile will be both "big" and "slow", and not all that useful for systems programming.

There should not be any difference.

> > The trouble is how it percolates through the typing system, affecting everything from function overloading to template partial ordering to template argument deduction to template partial specialization. It just winds up adding a great deal of complexity.
> Then simply outlaw "volatile" for ALL those uses!  I want a fast, simple, clean volatile.  Not a new type (sub)system.

Offhand, I think it would be hard (meaning kludgy compiler code) to
distinguish them.