Hello,

I have one simple question:

Export in D, is equal to volatile in C++

Thanks

--
Luigi

"Luigi" <igiul.reverse@email.it> wrote in message news:alisiu$2599$1@digitaldaemon.com...
> Export in D, is equal to volatile in C++

No, export means it is made available to users of the DLL. There is no volatile in D, as in my opinion volatile is next to useless in real applications.

> No, export means it is made available to users of the DLL. There is no volatile in D, as in my opinion volatile is next to useless in real applications.

Ok, thanks

--
Luigi

Walter wrote:

> There is no
> volatile in D, as in my opinion volatile is next to useless in real
> applications.

Arrgh!  This is true only from the perspective of a single program running on a memory-protected system.

The vast majority of the code I write runs on systems with no MMU, on systems where multiple processors share the same memory, and on systems where applications need direct access to hardware.

In all these cases, and in all their possible intersections and unions, "volatile" is useful simply to tell the compiler to NEVER enregister a variable.  That is, all references to a given variable should go "to the metal" every time.  No caching of such data items anywhere, ever.

With "volatile", I can use any level of abstraction to represent my data.  I can map a structure over raw memory or hardware, and I can pass pointers to such data that retain the volatile property.

When working with compilers that lacked a fully functional "volatile" (sometimes ignored by compilers, like its anti-twin "register") I've had to resort to cumbersome indirect dynamic dereferences or inline assembler just to bypass a compiler "feature".  And in order to guarantee I was smarter than the peep-hole optimizer, I'd still have to disassemble the binary to be sure.  (Note:  The common practice of examining the compiler assembly output is insufficient:  Many assemblers, most notably Intel's, also have peep-hole optimizers!)

It gets worse:  Most CPUs do some form of data bus caching, even those without MMUs.  On such platforms, "volatile" must also ensure it correctly drills through the hardware cache.

"Volatile" may be an unnecessary feature to many, but if D is to truly be a "systems programming language", it is a mandatory requirement.

Unless, of course, the equivalent functionality already exists in D, and this discussion is really about syntactic sugar.  In which case, I say give me my sugar!  I'm used to having it in C.

Otherwise, it seems to me it will be impossible to use D to write any "serious" low-level code, not even a simple DMA handler (often needed when working with custom hardware in FPGAs because it is a simple and powerful interface).

Without that capability, just what kind of "systems programming language" could D really be?  C++ lets me write device drivers.  Java doesn't. Focusing on system programming capabilities alone (not implementation), which one is D going to be most like?

My entire interest in D focuses on pushing the power of "reasonable" OOP and "useful" GC further down in to embedded systems.  Ideally, over 99% of all the programming could be done in D, using or avoiding D language features as appropriate to the context, with just a minimal smattering of assembler "glue" code (preferably inlined in D as well).

Embedded apps are like small operating systems in that they need to be able to marshall all the resources of the system.  Could I write an OS 99% in D?


-BobC

"Robert W. Cunningham" <FlyPG@users.sourceforge.net> wrote in message news:3D7D3F59.E537224C@users.sourceforge.net...
> Walter wrote:
> > There is no
> > volatile in D, as in my opinion volatile is next to useless in real
> > applications.
> Arrgh!  This is true only from the perspective of a single program running on a memory-protected system.

Ah, I was hoping for a discussion!

> The vast majority of the code I write runs on systems with no MMU, on systems where multiple processors share the same memory, and on systems where applications need direct access to hardware.

Ok.

> In all these cases, and in all their possible intersections and unions, "volatile" is useful simply to tell the compiler to NEVER enregister a variable.  That is, all references to a given variable should go "to the metal" every time.  No caching of such data items anywhere, ever.
>
> With "volatile", I can use any level of abstraction to represent my data.  I can map a structure over raw memory or hardware, and I can pass pointers to such data that retain the volatile property.
>
> When working with compilers that lacked a fully functional "volatile" (sometimes ignored by compilers, like its anti-twin "register") I've had to resort to cumbersome indirect dynamic dereferences or inline assembler just to bypass a compiler "feature".  And in order to guarantee I was smarter than the peep-hole optimizer, I'd still have to disassemble the binary to be sure.  (Note:  The common practice of examining the compiler assembly output is insufficient:  Many assemblers, most notably Intel's, also have peep-hole optimizers!)

The Digital Mars inline assembler is w-y-w-i-w-y-g.

> It gets worse:  Most CPUs do some form of data bus caching, even those without MMUs.  On such platforms, "volatile" must also ensure it correctly drills through the hardware cache.
>
> "Volatile" may be an unnecessary feature to many, but if D is to truly be a "systems programming language", it is a mandatory requirement.
>
> Unless, of course, the equivalent functionality already exists in D, and this discussion is really about syntactic sugar.  In which case, I say give me my sugar!  I'm used to having it in C.

I've always found I needed to use a LOCK prefix anyway, so resorted to inline assembler.

> Otherwise, it seems to me it will be impossible to use D to write any "serious" low-level code, not even a simple DMA handler (often needed when working with custom hardware in FPGAs because it is a simple and powerful interface).

Why? What volatility does a DMA handler have?

> Without that capability, just what kind of "systems programming language" could D really be?  C++ lets me write device drivers.  Java doesn't. Focusing on system programming capabilities alone (not implementation), which one is D going to be most like?

You can still read/write to any memory address, including I/O ports.

> My entire interest in D focuses on pushing the power of "reasonable" OOP and "useful" GC further down in to embedded systems.  Ideally, over 99% of all the programming could be done in D, using or avoiding D language features as appropriate to the context, with just a minimal smattering of assembler "glue" code (preferably inlined in D as well).
>
> Embedded apps are like small operating systems in that they need to be able to marshall all the resources of the system.  Could I write an OS 99% in D?

I don't see why not. I've looked at the linux kernel sources, and don't see anything there D can't do.

>> Without that capability, just what kind of "systems programming language" could D really be?  C++ lets me write device drivers.  Java doesn't. Focusing on system programming capabilities alone (not implementation), which one is D going to be most like?
>
>You can still read/write to any memory address, including I/O ports.

What happens when the memory is just memory-mapped I/O on an add-in card?  Every memory read gives you new volatile data.  There is no LOCK prefix needed in this case, but you need to be able to tell the compiler not to enregister this data and to go get it again on each reference.

"Joe Battelle" <Joe_member@pathlink.com> wrote in message news:all4et$2qg8$1@digitaldaemon.com...
> What happens when the memory is just memory-mapped I/O on an add-in card?
Every
> memory read gives you new volatile data.  There is no LOCK prefix needed
in this
> case, but you need to be able to tell the compiler not to enregister this
data
> and to go get it again on each reference.

That can be resolved by crafting a function like:

    byte read_byte_from_volatile_location(byte *p);

For efficiency, the compiler can even make it an intrinsic function (like
sin(), cos(), etc.). It solves the problem without the volatile type
modifier permeating the type system and adding pages of complexity to
overloading, type deduction, partial specialization, partial ordering, etc.

Walter wrote:

> "Joe Battelle" <Joe_member@pathlink.com> wrote in message
> news:all4et$2qg8$1@digitaldaemon.com...
> 
>>What happens when the memory is just memory-mapped I/O on an add-in card?
>>
> Every
> 
>>memory read gives you new volatile data.  There is no LOCK prefix needed
>>
> in this
> 
>>case, but you need to be able to tell the compiler not to enregister this
>>
> data
> 
>>and to go get it again on each reference.
>>
> 
> That can be resolved by crafting a function like:
> 
>     byte read_byte_from_volatile_location(byte *p);
> 
> For efficiency, the compiler can even make it an intrinsic function (like
> sin(), cos(), etc.). It solves the problem without the volatile type
> modifier permeating the type system and adding pages of complexity to
> overloading, type deduction, partial specialization, partial ordering, etc.

There could be a single throttle point; that would stick everything in one section of the code generator and a small expression type, using a "volatile" intrinsic:

   int mouse_x; /* This is volatile */

   int a, b;

   a = volatile (mouse_x);
   b = volatile (mouse_x);

Afterwards, a and b are potentially different.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D7E85CB.2030805@users.sourceforge.net...
> There could be a single throttle point; that would stick everything in one section of the code generator and a small expression type, using a "volatile" intrinsic:
>
>     int mouse_x; /* This is volatile */
>
>     int a, b;
>
>     a = volatile (mouse_x);
>     b = volatile (mouse_x);
>
> Afterwards, a and b are potentially different.

Yes, that might be a better way to do it.

>>     a = volatile (mouse_x);
>>     b = volatile (mouse_x);
>>
>> Afterwards, a and b are potentially different.
>
>Yes, that might be a better way to do it.

Your function approach works, but it is really nice to be able to lay a structure over a portion of memory-mapped I/O, call the whole darn thing volatile and reference away.  I much prefer this to introducing more intrinsics.