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

"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
intrinsics.

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

"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
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!

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.

>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;
}
}

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
> intrinsics.
>
> The downside is the huge increase in complexity of the type system.

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...

"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
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.

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
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;
> }
> }

That's probably a better solution. The trouble with volatile as a type modifier is its ripple effects throughout the typing system.

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
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.
> >
> > The downside is the huge increase in complexity of the type system.
>
>
>

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
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.
> > >
> > > The downside is the huge increase in complexity of the type system.

>Ok, but in the particular example here it cannot be hoisted anyway because the assignment to the array log[] invalidates all pointer references.
OK.  I guess my point is that it doesn't have to.  I mean, I think without the 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.
Understood.  And I think it's very reasonable to do things differently than in C++ if it keeps the complexity of the compiler down.