www.digitalmars.com         C & C++   DMDScript  

D - Export and Volatile

reply "Luigi" <igiul.reverse email.it> writes:
Hello,

I have one simple question:

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

Thanks

--
Luigi
Sep 09 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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.
Sep 09 2002
next sibling parent "Luigi" <igiul.reverse email.it> writes:
 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
Sep 09 2002
prev sibling parent reply "Robert W. Cunningham" <FlyPG users.sourceforge.net> writes:
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
Sep 09 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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.

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.
Sep 09 2002
parent reply Joe Battelle <Joe_member pathlink.com> writes:
 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.
Sep 10 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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?

 memory read gives you new volatile data.  There is no LOCK prefix needed

 case, but you need to be able to tell the compiler not to enregister this

 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.
Sep 10 2002
parent reply Burton Radons <loth users.sourceforge.net> writes:
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?

memory read gives you new volatile data.  There is no LOCK prefix needed

case, but you need to be able to tell the compiler not to enregister this

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.
Sep 10 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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.
Sep 10 2002
parent reply Joe Battelle <Joe_member pathlink.com> writes:
     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.
Sep 10 2002
next sibling parent reply "Robert W. Cunningham" <FlyPG users.sourceforge.net> writes:
Joe Battelle wrote:

     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.

Same here! In the old days, we had to write lots of #defines and do peeks and pokes to access hardware from userland. Walter's function-based approach would force us back to those bad old days (with better naming, but the same functionality). Being able to overlay an intricate structure over a hardware interface abstracts away a huge portion of the hassle of writing to the bare metal. Lack of a true volatile attribute will exclude D from use on any system I build. It is that important to what I do and how I do it. D has to win HANDS DOWN over C in every domain to break into embedded systems. Don't think small in this area, unless you are prepared to abandon it. C++ has only a limited presence in embedded systems, and poses no competition to D. Unless, of course, D lacks volatile. Then C++ wins, despite the hassle and baggage. Just today I had to write a routine to talk to a "gas gauge" chip used to monitor a Li-ion battery. I simply declared a struct that mapped 1:1 to the device's registers, declared a pointer to a volatile instance of that structure (different, of course, from a volatile pointer to an instance), and was programming the device in C within minutes. The whole thing, including the time needed to read the cryptic spec sheet, examine the board schematics, verify the chip select address decode logic in the FPGA, craft the struct and write the code, was done in about 4 hours. Without volatile, it could easily have taken that long just to write all the #defines for the gas gauge register locations and content. Ugh. Don't even try to make me go back to #defines and PEEK/POKE! -BobC
Sep 10 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Robert W. Cunningham" <FlyPG users.sourceforge.net> wrote in message
news:3D7E9EF8.3A33B3C2 users.sourceforge.net...
 Just today I had to write a routine to talk to a "gas gauge" chip used to

 Li-ion battery.  I simply declared a struct that mapped 1:1 to the

 registers, declared a pointer to a volatile instance of that structure

 of course, from a volatile pointer to an instance), and was programming

 in C within minutes.  The whole thing, including the time needed to read

 cryptic spec sheet, examine the board schematics, verify the chip select

 decode logic in the FPGA, craft the struct and write the code, was done in

 hours.

 Without volatile, it could easily have taken that long just to write all

 #defines for the gas gauge register locations and content.  Ugh.  Don't

 make me go back to #defines and PEEK/POKE!

Ok, but why did it need to be volatile access? I'm not trying to be obtuse here, I'm trying to understand the problem you're solving.
Sep 10 2002
parent reply Joe Battelle <Joe_member pathlink.com> writes:
Ok, but why did it need to be volatile access? I'm not trying to be obtuse
here, I'm trying to understand the problem you're solving.

I won't steal Robert's thunder, but I guess I don't understand what your objection is to the volatile construct. When interfacing using memory-mapped I/O (as opposed to Port I/O) you frequently deal with pointers to structs that aren't pointing to main memory. The "memory" is just some latch on the other side of an address decoder that has a transient value. The data shouldn't ever be cached. Think of a simple data acquisition system that has three hardware registers all memory-mapped on a PCI-bus card. Look at the following example: timestamp and data dereferences better not be enregistered or hoisted outside the loop or you're in trouble. volatile struct DataAcq { int timestamp; // Base+0 int count; // Base+4 int data; // Base+8 } DataAcq * p = cast(DataAcq *) 0xF0000000; // Base address int[] log; for (int i = 0; i < p.count; ++i) { if (p.timestamp < endtime) log[i] = p.data; else break; } ---------------------- Now I would be just as happy doing this: for (int i = 0; i < p.count; ++i) { volatile(p) { if (p.timestamp < endtime) log[i] = p.data; else break; } } ----------------------- or even just something generic that says don't enregister or hoist any pointer dereferences in the block of code. for (int i = 0; i < p.count; ++i) { volatile() { if (p.timestamp < endtime) log[i] = p.data; else break; } }
Sep 11 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Joe Battelle" <Joe_member pathlink.com> wrote in message
news:almuqb$22cm$1 digitaldaemon.com...
 Think of a simple data acquisition system that has three hardware

 memory-mapped on a PCI-bus card.  Look at the following example: timestamp

 data dereferences better not be enregistered or hoisted outside the loop

 you're in trouble.

Ok, but in the particular example here it cannot be hoisted anyway because the assignment to the array log[] invalidates all pointer references.
 volatile struct DataAcq {
 int timestamp; // Base+0
 int count;     // Base+4
 int data;      // Base+8
 }

 DataAcq * p = cast(DataAcq *) 0xF0000000; // Base address
 int[] log;

 for (int i = 0; i < p.count; ++i) {
 if (p.timestamp < endtime)
 log[i] = p.data;
 else
 break;
 }

 ----------------------
 Now I would be just as happy doing this:

 for (int i = 0; i < p.count; ++i) {
 volatile(p) {
 if (p.timestamp < endtime)
 log[i] = p.data;
 else
 break;
 }
 }

 -----------------------
 or even just something generic that says don't enregister or hoist any

 dereferences in the block of code.

 for (int i = 0; i < p.count; ++i) {
 volatile() {
 if (p.timestamp < endtime)
 log[i] = p.data;
 else
 break;
 }
 }

That's probably a better solution. The trouble with volatile as a type modifier is its ripple effects throughout the typing system.
Sep 11 2002
parent reply Joe Battelle <Joe_member pathlink.com> writes:
Ok, but in the particular example here it cannot be hoisted anyway because
the assignment to the array log[] invalidates all pointer references.

volatile specifier, it would be natural for an optimizer to deref p.data once above the loop and put it in a register. I don't see how assigning the deref'd value to an array element would keep the deref (not the assignment) from being hoisted in all D implementations.
That's probably a better solution. The trouble with volatile as a type
modifier is its ripple effects throughout the typing system.

C++ if it keeps the complexity of the compiler down.
Sep 11 2002
parent "Walter" <walter digitalmars.com> writes:
"Joe Battelle" <Joe_member pathlink.com> wrote in message
news:alnutu$i46$1 digitaldaemon.com...
Ok, but in the particular example here it cannot be hoisted anyway


the assignment to the array log[] invalidates all pointer references.


 volatile specifier, it would be natural for an optimizer to deref p.data

 above the loop and put it in a register.  I don't see how assigning the

 value to an array element would keep the deref (not the assignment) from

 hoisted in all D implementations.

The optimizer has to be painfully conservative. In this case, there's no way the optimizer can verify that the array log[] does not overlap whatever p points to. Do people write code like that? Often enough - and the people that do are usually the ones unable to figure out why their code breaks when optimized and they blame the compiler. It's the famed C 'aliasing' problem.
That's probably a better solution. The trouble with volatile as a type
modifier is its ripple effects throughout the typing system.


 C++ if it keeps the complexity of the compiler down.

Yes. Glad you understand! It's important for me, in designing a language, to: 1) understand what the problem is, not just implement a solution If I understand the problem correctly, I have a chance at implementing a better solution. 2) recognize the scope of the problem If the scope of the problem is fairly small, it can justify a more targetted solution. For example, volatile permeates partial specialization rules in C++ templates - but why on earth would you be using such to access hardware registers? But you can't get away from it because volatile is a type modifier, so everything that uses types must account for it. It's using a sledgehammer to squash a flea.
Sep 11 2002
prev sibling parent reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
What about defining a class with gettors and settors?  You would still 
have to do some of the hard work, but it would allow you to have 
something like a struct with volatile members...
Sep 11 2002
parent reply "Robert W. Cunningham" <FlyPG users.sourceforge.net> writes:
Russell Lewis wrote:

 What about defining a class with gettors and settors?  You would still
 have to do some of the hard work, but it would allow you to have
 something like a struct with volatile members...

That's still a function call, which amount to nothing more than a PEEK or POKE. Plus, whatever you do within the gettor/settor could still get cached! You really need to be able to "drill-down" to the physical environment. That is, if I want a bus cycle to occur (read or write), then by God it must occur when and how I want it to! Presently, not only does D not allow you to prevent enregistration, it does not allow you to atomically bypass the CPU cache. Both are needed tigether in order to obtain true "volatile" behavior. -BobC
Sep 11 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Robert W. Cunningham" <FlyPG users.sourceforge.net> wrote in message
news:3D7FD186.4480CC4A users.sourceforge.net...
 Presently, not only does D not allow you to prevent enregistration, it
 does not allow you to atomically bypass the CPU cache.  Both are needed
 tigether in order to obtain true "volatile" behavior.

I've got the "volatile" statement now implemented, as in: volatile a = *p; It will prevent any caching of values into and out of the volatile statement.
Sep 14 2002
next sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Walter wrote:
 "Robert W. Cunningham" <FlyPG users.sourceforge.net> wrote in message
 news:3D7FD186.4480CC4A users.sourceforge.net...
 
Presently, not only does D not allow you to prevent enregistration, it
does not allow you to atomically bypass the CPU cache.  Both are needed
tigether in order to obtain true "volatile" behavior.

I've got the "volatile" statement now implemented, as in: volatile a = *p; It will prevent any caching of values into and out of the volatile statement.

Uh... struct Registers { struct Data { int a; } Data data; int a () { return volatile data.a; } void a (int value) { data.a = value; } } Would that work, or would the get property have to be: int a () { int value; volatile value = data.a; return value; } If so, that's pretty heavy stuff for what will be the most common usage. I'd rather have a function that's turned intrinsic in semantic0, as it retains the "easy to parse dumbly" rule and doesn't have bad worst cases for syntax.
Sep 14 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:3D842697.6080208 users.sourceforge.net...
      struct Registers
      {
          struct Data
          {
              int a;
          }

          Data data;

          int a () { return volatile data.a; }
          void a (int value) { data.a = value; }
      }

 Would that work, or would the get property have to be:

      int a ()
      {
          int value;
          volatile value = data.a;
          return value;
      }

 If so, that's pretty heavy stuff for what will be the most common usage.
   I'd rather have a function that's turned intrinsic in semantic0, as it
 retains the "easy to parse dumbly" rule and doesn't have bad worst cases
 for syntax.

volatile return data.a; should work fine.
Sep 14 2002
parent reply Burton Radons <loth users.sourceforge.net> writes:
Walter wrote:
 "Burton Radons" <loth users.sourceforge.net> wrote in message
 news:3D842697.6080208 users.sourceforge.net...
 
     struct Registers
     {
         struct Data
         {
             int a;
         }

         Data data;

         int a () { return volatile data.a; }
         void a (int value) { data.a = value; }
     }

Would that work, or would the get property have to be:

     int a ()
     {
         int value;
         volatile value = data.a;
         return value;
     }

If so, that's pretty heavy stuff for what will be the most common usage.
  I'd rather have a function that's turned intrinsic in semantic0, as it
retains the "easy to parse dumbly" rule and doesn't have bad worst cases
for syntax.

volatile return data.a; should work fine.

Oh... kay. So what's the advantage over a function? Why does it earn its additional parsing complexity? This also requires the compiler to have knowledge of every statement and expression and how to make it non-caching; the function-based method is just a guaranteed dereference. The property-based read is going to be the most common - I'd even predict that using stuff like "volatile for..." will be consigned to the criminally insane, as leaving it to the caller to manage volatile is a bad idea (but as a property it's fine). So supporting it doesn't look to have much particular extra value.
Sep 15 2002
parent "Walter" <walter digitalmars.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:3D8466B4.3080008 users.sourceforge.net...
 volatile return data.a;

 should work fine.

Oh... kay. So what's the advantage over a function?

It's more convenient. No dummy functions.
 Why does it earn
 its additional parsing complexity?

Not sure what you mean. A volatile statement is almost no code to implement.
  This also requires the compiler to
 have knowledge of every statement and expression and how to make it
 non-caching; the function-based method is just a guaranteed dereference.

No, it's pretty trivial to implement. It requires no knowledge of the statements being processed. Each statement gets processed into a sequence of basic blocks. The compiler just marks those blocks as being conceptually like asm blocks - already taken care of within the optimizer.
 The property-based read is going to be the most common - I'd even
 predict that using stuff like "volatile for..." will be consigned to the
 criminally insane, as leaving it to the caller to manage volatile is a
 bad idea (but as a property it's fine).  So supporting it doesn't look
 to have much particular extra value.

I was thinking it would be good for things like: for (int i = 0; i < 1000; i++) volatile sum += *p;
Sep 15 2002
prev sibling parent reply "Robert W. Cunningham" <FlyPG users.sourceforge.net> writes:
Walter wrote:

 "Robert W. Cunningham" <FlyPG users.sourceforge.net> wrote in message
 news:3D7FD186.4480CC4A users.sourceforge.net...
 Presently, not only does D not allow you to prevent enregistration, it
 does not allow you to atomically bypass the CPU cache.  Both are needed
 tigether in order to obtain true "volatile" behavior.

I've got the "volatile" statement now implemented, as in: volatile a = *p; It will prevent any caching of values into and out of the volatile statement.

Hmmm... That's very different from what I'm used to. I'd prefer to be able to say "when taking the value of this thing, treat it as volatile, no matter how it is dereferenced, or when, or where". Suppse I have a global pointer to a hardware register (say, a 32-bit real-time clock/counter). Adding "volatile" to each and every use will be a nightmare. Missing just one could ruin an entire application, and be next to impossible to detect and debug. Which means all my volatile items would probably need to be single-reference, and thus need to be wrapped within a function call or an object. I'd need an explicit "inline" statement to ensure I can access the dereferenced pointer value in "real-time". Unless I have misunderstood the meaning and use, this interpretation of "volatile" looks like a non-starter to me. -BobC
Sep 15 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Robert W. Cunningham" <FlyPG users.sourceforge.net> wrote in message
news:3D84342E.948C934 users.sourceforge.net...
 Walter wrote:
 "Robert W. Cunningham" <FlyPG users.sourceforge.net> wrote in message
 news:3D7FD186.4480CC4A users.sourceforge.net...
 Presently, not only does D not allow you to prevent enregistration, it
 does not allow you to atomically bypass the CPU cache.  Both are



 tigether in order to obtain true "volatile" behavior.

volatile a = *p; It will prevent any caching of values into and out of the volatile statement.


It is a different way of looking at the issue, but I think it does address your concerns.
 I'd prefer to be able to say "when taking the value of this thing, treat

 as volatile, no matter how it is dereferenced, or when, or where".

That's the type modifier approach.
 Suppse I have a global pointer to a hardware register (say, a 32-bit
 real-time clock/counter).
 Adding "volatile" to each and every use will be a
 nightmare.  Missing just one could ruin an entire application, and be next
 to impossible to detect and debug.

The compiler isn't that good at caching values. <g> Caching is nearly always very localized, and is flushed anyway when any assignments through a pointer are done. The only time this can be an issue is if two reads are done with no intervening indirect assignments of any sort. That includes assigning to any globals/statics, assigning to arrays, or calling functions.
 Which means all my volatile items would probably need to be
 single-reference, and thus need to be wrapped within a function call or an
 object.

You could do it that way - and is a common oo technique with property gettors and settors. The gettors and settors get inline expanded, so there's no performance penalty for using them.
 I'd need an explicit "inline" statement to ensure I can access the
 dereferenced pointer value in "real-time".

I think that would be unnecessary. Even the most basic inlining capability will inline a function that consists of nothing but return *p;
 Unless I have misunderstood the meaning and use, this interpretation of
 "volatile" looks like a non-starter to me.

Can you post a bit of code that would cause particular grief?
Sep 15 2002
parent reply "Robert W. Cunningham" <FlyPG users.sourceforge.net> writes:
Walter wrote:

 "Robert W. Cunningham" <FlyPG users.sourceforge.net> wrote in message
 news:3D84342E.948C934 users.sourceforge.net...
 Suppse I have a global pointer to a hardware register (say, a 32-bit
 real-time clock/counter).
 Adding "volatile" to each and every use will be a
 nightmare.  Missing just one could ruin an entire application, and be next
 to impossible to detect and debug.

The compiler isn't that good at caching values. <g> Caching is nearly always very localized, and is flushed anyway when any assignments through a pointer are done. The only time this can be an issue is if two reads are done with no intervening indirect assignments of any sort. That includes assigning to any globals/statics, assigning to arrays, or calling functions.

It seems you may have a biased view of the vast array of caching strategies used by the wide variety of processors out there! Generally, read and write (and instruction fetch) caching are handled by separate, independent hardware subsystems. Whatever caching the compiler may or may not do is secondary to whatever hardware caching may be going on. I don't really care all that much about assignment (write) caching (for the hardware, I configure it when the processor boots and can generally forget about it). I do care very much about access (read) caching (since the hardware read cache is always enabled, and I want to bypass it when I need to). 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.
 Which means all my volatile items would probably need to be
 single-reference, and thus need to be wrapped within a function call or an
 object.

You could do it that way - and is a common oo technique with property gettors and settors. The gettors and settors get inline expanded, so there's no performance penalty for using them.

Other than they are MUCH heavier than simply having a *p wherever I need to access a volatile value. A typical snippet, say for a timer: if (*p > last_time) { ... } I do this all the time in C. It is especially handy when many items need to be tested very quickly. Such as an array of 8000 IPC mailboxes. If any access were to fetch a prior value from a hardware cache or a CPU register, the program would not be getting the data it needs (which is a true read cycle to the hardware).
 I'd need an explicit "inline" statement to ensure I can access the
 dereferenced pointer value in "real-time".

I think that would be unnecessary. Even the most basic inlining capability will inline a function that consists of nothing but return *p;

It just seems like extra window dressing (baggage) and ahssle for D to do something that is so easy in C. It's like training a dog: If I say "fetch" and the dog doesn't fetch, the dog will be disciplined. Well, OK, it's not exactly like training a dog: If I say "fetch" and my compiler doesn't do a true "fetch", the compiler will be taken out and shot. -BobC
Sep 15 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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

 a small part of what "volatile" must handle.

How should code be generated differently?
 Other than they are MUCH heavier than simply having a *p wherever I need

 access a volatile value.
 A typical snippet, say for a timer:

 if (*p > last_time) { ... }

 I do this all the time in C.  It is especially handy when many items need

 tested very quickly.  Such as an array of 8000 IPC mailboxes.
 If any access were to fetch a prior value from a hardware cache or a CPU
 register, the program would not be getting the data it needs (which is a

 read cycle to the hardware).

p.get() is only 5 characters more, and no extra code is actually generated.
 It just seems like extra window dressing (baggage) and ahssle for D to do
 something that is so easy in C.

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.
Sep 15 2002
parent reply "Robert W. Cunningham" <FlyPG users.sourceforge.net> writes:
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

 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! I don't have to look at CPU manuals any more: These days, GCC does "volatile" well on all platforms I use it on. Which probably means that GCC-D will likely have a "proper" volatile, since GCC itself already has the code to handle it on all platforms. That's good enough for me!
 Other than they are MUCH heavier than simply having a *p wherever I need

 access a volatile value.
 A typical snippet, say for a timer:

 if (*p > last_time) { ... }

 I do this all the time in C.  It is especially handy when many items need

 tested very quickly.  Such as an array of 8000 IPC mailboxes.
 If any access were to fetch a prior value from a hardware cache or a CPU
 register, the program would not be getting the data it needs (which is a

 read cycle to the hardware).

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"? If there is absolutely zero difference (it is one or two instructions), then you and I are describing identical functionality, only from different perspectives. 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.
 It just seems like extra window dressing (baggage) and ahssle for D to do
 something that is so easy in C.

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. I only need "volatile" for specific pointers that, when dereferenced, will ALWAYS drill through the cache and read the hardware directly. It need not be elegant or general: "Possible" and "fast" will suffice. Hmmm... If the implementation of your proposed volatile syntax is both light and fast, I suppose I could make your initial proposal meet my needs, but I'd need to add a notational layer that would need to be handled by a preprocessor. If that will work, I'm fine with it. For example, I'd place my "volatile" declarations in encoded comments, use an initial preprocessor pass to extract the list of variable names that are "volatile", then use a final preprocessor pass to wrap all references with your notation. So long as I don't have to do it manually, it will probably work for me. I've written several such systems that used encoded comments. The key is to do so in a way that keeps debugging sane enough to use the original source file (instead of the post-processed file). I don't see that being a problem here. But I'd much prefer a solution that didn't demand preprocessing for it to be both general and robust. Preprocessing would kill one of D's special characteristics. But it would be OK if it enabled the use of D for direct hardware-level programming. Hmmmm.... I could do that same transformation if I had access to your parse tree. Which means your compiler should be able to do it just as easily. -BobC
Sep 17 2002
next sibling parent Mark Evans <Mark_member pathlink.com> writes:
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
Sep 17 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"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



 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

 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

 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


 But how much more code is generated?  More importantly, how many times

 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),

 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.

clean volatile. Not a new type (sub)system.

Offhand, I think it would be hard (meaning kludgy compiler code) to distinguish them.
Sep 18 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Joe Battelle" <Joe_member pathlink.com> wrote in message
news:alm5h9$15fv$1 digitaldaemon.com...
 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

The downside is the huge increase in complexity of the type system.
Sep 10 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
If you can have it work as a storage class that may be good enough.

I'm not sure it's possible!

Sean


"Walter" <walter digitalmars.com> wrote in message
news:almj8g$1k8u$1 digitaldaemon.com...
 "Joe Battelle" <Joe_member pathlink.com> wrote in message
 news:alm5h9$15fv$1 digitaldaemon.com...
 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

The downside is the huge increase in complexity of the type system.

Sep 11 2002
parent reply "Walter" <walter digitalmars.com> writes:
While const will work as a storage class, it doesn't really extend to
volatile. This is because it's easy to think of constants, but with
volatiles you'll have pointers to volatiles.

"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:aln4pi$292b$1 digitaldaemon.com...
 If you can have it work as a storage class that may be good enough.

 I'm not sure it's possible!

 Sean


 "Walter" <walter digitalmars.com> wrote in message
 news:almj8g$1k8u$1 digitaldaemon.com...
 "Joe Battelle" <Joe_member pathlink.com> wrote in message
 news:alm5h9$15fv$1 digitaldaemon.com...
 Your function approach works, but it is really nice to be able to lay



 structure over a portion of memory-mapped I/O, call the whole darn



 volatile and reference away.  I much prefer this to introducing more

The downside is the huge increase in complexity of the type system.


Sep 11 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
You can have pointers to constants too.  How do you deal with that?

I'm sorry... I don't have a problem with C++ type modifiers.  In fact I'd
rather have more modifiers, even user-defined ones.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:alnshj$4fo$3 digitaldaemon.com...
 While const will work as a storage class, it doesn't really extend to
 volatile. This is because it's easy to think of constants, but with
 volatiles you'll have pointers to volatiles.

 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:aln4pi$292b$1 digitaldaemon.com...
 If you can have it work as a storage class that may be good enough.

 I'm not sure it's possible!

 Sean


 "Walter" <walter digitalmars.com> wrote in message
 news:almj8g$1k8u$1 digitaldaemon.com...
 "Joe Battelle" <Joe_member pathlink.com> wrote in message
 news:alm5h9$15fv$1 digitaldaemon.com...
 Your function approach works, but it is really nice to be able to




 a
 structure over a portion of memory-mapped I/O, call the whole darn



 volatile and reference away.  I much prefer this to introducing more

The downside is the huge increase in complexity of the type system.



Sep 11 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:alnu26$e30$1 digitaldaemon.com...
 You can have pointers to constants too.  How do you deal with that?

D doesn't have pointers to constants as a type. I eventually abandoned all use of const pointers in my C++ code, having discovered: 1) It never once saved me from a bug. 2) There was a significant nuisance involved in getting it all const-correct. 3) The optimizer can't make use of const info, since one can legitimately cast away const-ness. 4) I write compilers, and I still have a hard time remembering if the const goes to the left of the * or the right, or exactly where it goes in more complex type declarations. While const as a storage class makes sense, and is implemented in D, const as a type does not.
 I'm sorry... I don't have a problem with C++ type modifiers.  In fact I'd
 rather have more modifiers, even user-defined ones.

Ok <g>.
Sep 11 2002
next sibling parent reply "Robert W. Cunningham" <FlyPG users.sourceforge.net> writes:
Walter wrote:

 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:alnu26$e30$1 digitaldaemon.com...
 You can have pointers to constants too.  How do you deal with that?

D doesn't have pointers to constants as a type. I eventually abandoned all use of const pointers in my C++ code, having discovered: 1) It never once saved me from a bug. 2) There was a significant nuisance involved in getting it all const-correct. 3) The optimizer can't make use of const info, since one can legitimately cast away const-ness. 4) I write compilers, and I still have a hard time remembering if the const goes to the left of the * or the right, or exactly where it goes in more complex type declarations. While const as a storage class makes sense, and is implemented in D, const as a type does not.
 I'm sorry... I don't have a problem with C++ type modifiers.  In fact I'd
 rather have more modifiers, even user-defined ones.

Ok <g>.

I agree! Let's replace "const" with "ROM", just to make the difference perfectly clear. The implementation should simply disallow write cycles to that location. This can be supported in the compiler, but it can be absolutely guaranteed by placing consts in a separate memory area/page and setting the appropriate MMU bits! Similarly, the compiler can support "volatile", but volatile items should be assigned MMU protection flags that force cache invalidation upon access (which is how hardware does volatile). When there is no MMU, forcing "read-thru" on a cache can be a bit harder, but most embedded CPUs allow you to enable cache for only a specified memory range. Anything outside that range (no matter if it is RAM, ROM or hardware) cannot and will not be cached. Just be sure the hardware designers keep all the cacheable stuff contiguous within the memory map, and all will be well. For example, on my embedded multiprocessor projects, I often intentionally place part of the RAM outside the cache. It may then be used as mailboxes and semaphores by all processors, with the guarantee the all processors have the same view of that memory at all times. (And all embedded processors I'm aware of support an atomic read-modify-write cycle, so again hardware helps.) The central OS has to enforce the "guarantee" for processes residing in common memory that is cached. All RTOS's I've used do this quite well. -BobC
Sep 11 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Robert W. Cunningham" <FlyPG users.sourceforge.net> wrote in message
news:3D7FD42F.DA459077 users.sourceforge.net...
 I agree!  Let's replace "const" with "ROM", just to make the difference
 perfectly clear.  The implementation should simply disallow write cycles

 that location.  This can be supported in the compiler, but it can be
 absolutely guaranteed by placing consts in a separate memory area/page and
 setting the appropriate MMU bits!

That's how const works as a storage class now - but it is up to the implementation if it wants to place them in ROM or not.
 Similarly, the compiler can support "volatile", but volatile items should

 assigned MMU protection flags that force cache invalidation upon access

 is how hardware does volatile).

 When there is no MMU, forcing "read-thru" on a cache can be a bit harder,

 most embedded CPUs allow you to enable cache for only a specified memory
 range.  Anything outside that range (no matter if it is RAM, ROM or

 cannot and will not be cached.  Just be sure the hardware designers keep

 the cacheable stuff contiguous within the memory map, and all will be

 For example, on my embedded multiprocessor projects, I often intentionally
 place part of the RAM outside the cache.  It may then be used as mailboxes

 semaphores by all processors, with the guarantee the all processors have

 same view of that memory at all times.  (And all embedded processors I'm

 of support an atomic read-modify-write cycle, so again hardware helps.)

 central OS has to enforce the "guarantee" for processes residing in common
 memory that is cached.  All RTOS's I've used do this quite well.

Do you see a "volatile" segment in the executable, analogously to a "rom" segment?
Sep 12 2002
parent "Robert W. Cunningham" <FlyPG users.sourceforge.net> writes:
Walter wrote:

 Do you see a "volatile" segment in the executable, analogously to a "rom"
 segment?

Yup! But only if there was no other way to obtain it. Since a compiler has to be targeted for its platform (CPU + OS), that targeting would have to provide the most logical implementation of volatile for that platform. Some CPU instruction sets have instruction prefixes that flag the associated data access(es) as "read-thru". For such CPUs, D could handle the entire issue itself, with no need for a volatile segment in the executable or OS support. The problem with volatile segments is that many of the standard executable formats don't allow for it, so it can't be presented to the loader. Fortunately, most platforms where this might be needed have implemented suitable extensions to the executable format. Extensions which, unfortunately, tend to be proprietary. Most platforms provide an OS call to map any memory segment as desired, so the needed logic can generally be added to the program startup code (the venerable cstart.a on C systems, which I've hacked many a time). -BobC
Sep 13 2002
prev sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
So there's nothing preventing you from writing code like this?

void BreakStuff(char* c)
{
    *c = 2;
}

int main()
{
    const char s = 1;
    BreakStuff(&s);
    printf("now it's %d\n",s); // prints 2.
}

Yeah that const storage class really does a lot of good.

You say const pointers never once saved you from a bug.  Congratulations.
They certainly help me out, if only as sanity checks.  If I can get the
compiler to verify any part of the correctness of my code, that's great.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:alo3rr$1ab1$1 digitaldaemon.com...
 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:alnu26$e30$1 digitaldaemon.com...
 You can have pointers to constants too.  How do you deal with that?

D doesn't have pointers to constants as a type. I eventually abandoned all use of const pointers in my C++ code, having discovered: 1) It never once saved me from a bug. 2) There was a significant nuisance involved in getting it all const-correct. 3) The optimizer can't make use of const info, since one can legitimately cast away const-ness. 4) I write compilers, and I still have a hard time remembering if the

 goes to the left of the * or the right, or exactly where it goes in more
 complex type declarations.

 While const as a storage class makes sense, and is implemented in D, const
 as a type does not.

 I'm sorry... I don't have a problem with C++ type modifiers.  In fact


 rather have more modifiers, even user-defined ones.

Ok <g>.

Sep 12 2002
next sibling parent reply Pavel Minayev <evilone omen.ru> writes:
Sean L. Palmer wrote:

 So there's nothing preventing you from writing code like this?
 
 void BreakStuff(char* c)
 {
     *c = 2;
 }
 
 int main()
 {
     const char s = 1;
     BreakStuff(&s);
     printf("now it's %d\n",s); // prints 2.
 }

You cannot write such code in D. You simply can't take address of a constant, because constants don't have addresses - they are just values, inserted in-place where constant is used. There is no such C++ nonsense as "constant variable" in D. Constant is a constant. Variable is a variable. You cannot use variables where constants are expected (in case-block, for example). Nor can you use constants where variables (and lvalues in general) are required - as out arguments etc
Sep 12 2002
parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
So it's not possible to force the compiler to pass a large constant by
reference?

It's often tricky to initialize something using initializer syntax.  How
will you build complex constants?  Do constants then always have to be known
at compile time?

If what you're saying is true I'd expect not to be able to build any kind of
structure out of constants such as a static const linked list.  Can't take
addresses, can't have lists.  Or graphs.

I suppose if nobody modifies a thing, and nobody externally can modify a
thing (not public) then for all intents and purposes it is const, but it's
sure nice to be able to keep people from modifying stuff without the
no-address restriction.  Is there a way to get around this?  People will
abuse it (witness mutable in C++, a way to declare a something as constant
to everyone but me.  Not constant so much as read-only;. at least to you.)

I guess there are two different things people use const for... real
constants (forever unchanging values) and read-only access protection.  D
only supports the former.

Sean

"Pavel Minayev" <evilone omen.ru> wrote in message
news:alqlrj$26ks$1 digitaldaemon.com...
 Sean L. Palmer wrote:

 So there's nothing preventing you from writing code like this?

 void BreakStuff(char* c)
 {
     *c = 2;
 }

 int main()
 {
     const char s = 1;
     BreakStuff(&s);
     printf("now it's %d\n",s); // prints 2.
 }

You cannot write such code in D. You simply can't take address of a constant, because constants don't have addresses - they are just values, inserted in-place where constant is used. There is no such C++ nonsense as "constant variable" in D. Constant is a constant. Variable is a variable. You cannot use variables where constants are expected (in case-block, for example). Nor can you use constants where variables (and lvalues in general) are required - as out arguments etc

Sep 13 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:alqi86$1pla$1 digitaldaemon.com...
 So there's nothing preventing you from writing code like this?

 void BreakStuff(char* c)
 {
     *c = 2;
 }

 int main()
 {
     const char s = 1;
     BreakStuff(&s);
     printf("now it's %d\n",s); // prints 2.
 }

 Yeah that const storage class really does a lot of good.

 You say const pointers never once saved you from a bug.  Congratulations.
 They certainly help me out, if only as sanity checks.  If I can get the
 compiler to verify any part of the correctness of my code, that's great.

I agree const as a type modifier does have some utility, I argue that it is minor compared with the cost of it. Some other points: o D does not allow taking the address of a const. Storage is not necessarilly even allocated for a const. o While D allows one to pass pointers around, it is almost never necessary to do so. Use out and inout parameters, which should give an error when used with const variables. o In D, if you do wind up using a pointer, it is for either interfacing with C or for doing something unusual that presumptively you're careful with. You can do anything with pointers in D - they're meant as a way around the typing system. o C doesn't help much there anyway, nothing stops casting away const'ness and modifying it. o The example will still print 1, not 2, because the implementation assumes that s is 1 and will substitute in the 1 in the printf. This is unlike C, since because const isn't guaranteed to be immutable, the compiler cannot make such an assumption.
Sep 14 2002