"Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:a7gom0$96n$1@digitaldaemon.com...
>> Oh, that's intuitive!  :-(  Add an extra empty function call in order to
> prevent the compiler from doing some undesirable optimization.  Uccccch! There has got to be a better way to address the problem than this.  I'm
not
> wedded to the "volatile" syntax and certainly not wedded to how C does things.  I was just pointing out, for those who have never done embedded programming, a major reason for that syntax.  If you can come up with a better solution (I guess I don't count the ones you have proposed so far
to
> be better.) than I am all for it.  You have showed such immagination in solving other C/C++ deficiencies that I have reason to hope you can solve this one elegantly.

I did have a thought. How about a keyword "sequence", as in:

    sequence;        // no caching across this keyword
    x = *p;            // *p is always reloaded

and:
    x = *p;
    sequence;        // *p is not cached

Walter wrote:

> I did have a thought. How about a keyword "sequence", as in:
>
>     sequence;        // no caching across this keyword
>     x = *p;            // *p is always reloaded
>
> and:
>     x = *p;
>     sequence;        // *p is not cached

Not a bad idea, although I don't like the idea that it removes ALL caching.
How about also adding a block syntax, where caching is only disabled on the
statements in the block:
    y = *q;
    sequence { x = *p; }// *p is NOT cached
    func(*q);    // *q is still cached

Pardon me if I'm being anal, but it seems like we should make 'sequence' impact as few lines of code as possible, so you can still mix good optimization into the same code block.

Of course, somebody's going to say (for their hardware registers) that they will have to add 'sequence' to every line that uses the register, and they're going to ask for a 'sequence' type modifier...and we're back to volatile. :(

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CA0F98A.265E2A99@deming-os.org...
> Walter wrote:
>
> > I did have a thought. How about a keyword "sequence", as in:
> >
> >     sequence;        // no caching across this keyword
> >     x = *p;            // *p is always reloaded
> >
> > and:
> >     x = *p;
> >     sequence;        // *p is not cached
>
> Not a bad idea, although I don't like the idea that it removes ALL
caching.
> How about also adding a block syntax, where caching is only disabled on
the
> statements in the block:
>     y = *q;
>     sequence { x = *p; }// *p is NOT cached
>     func(*q);    // *q is still cached
>
> Pardon me if I'm being anal, but it seems like we should make 'sequence'
impact
> as few lines of code as possible, so you can still mix good optimization
into
> the same code block.

Sequence won't affect enregistering variables, which is the big speed win, not caching. I think it will have a negligible affect on performance. Sequence fits nicely into the optimizer, because a special op is just inserted into the instruction stream that causes a 'kill' in the data flow analysis.

> Of course, somebody's going to say (for their hardware registers) that
they
> will have to add 'sequence' to every line that uses the register, and
they're
> going to ask for a 'sequence' type modifier...and we're back to volatile.
:(

Nobody's ever happy <g>.

(Apology: This message is HTML so a massive link might still be clickable.)

"Walter" <walter@digitalmars.com> wrote in message news:a7qrji$1bnv$1@digitaldaemon.com...
> 
> "Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:a7gom0$96n$1@digitaldaemon.com...
> >> Oh, that's intuitive!  :-(  Add an extra empty function call in order to
> > prevent the compiler from doing some undesirable optimization.  Uccccch! There has got to be a better way to address the problem than this.  I'm
> not
> > wedded to the "volatile" syntax and certainly not wedded to how C does things.  I was just pointing out, for those who have never done embedded programming, a major reason for that syntax.  If you can come up with a better solution (I guess I don't count the ones you have proposed so far
> to
> > be better.) than I am all for it.  You have showed such immagination in solving other C/C++ deficiencies that I have reason to hope you can solve this one elegantly.
> 
> I did have a thought. How about a keyword "sequence", as in:
> 
>     sequence;        // no caching across this keyword
>     x = *p;            // *p is always reloaded
> 
> and:
>     x = *p;
>     sequence;        // *p is not cached
> 
> 

This reminded me of something, so I did a quick Google search.

Go read a Linux Torvalds rant about SMP-safety, volatile, and "barrier()" (which is the Linux kernel's equivalent of "sequence").  And much of the thread is interesting, so I'm linking the whole thing (with this massive link - sorry).

http://groups.google.com/groups?hl=en&threadm=linux.kernel.Pine.LNX.4.33.0107231546430.7916-100000%40penguin.transmeta.com&rnum=5&prev=/groups%3Fq%3Dtorvalds%2Btransmeta%2Bbarrier%26hl%3Den

Boiled down, Torvalds believes that "volatile" as a storage class modifier is always wrong; if "volatile" semantics (whatever they are) are needed, then apply them at the moment of access (as with a cast).

-- 
Richard Krehbiel, Arlington, VA, USA
rich@kastle.com (work) or krehbiel3@comcast.net  (personal)

"Walter" <walter@digitalmars.com> wrote in message news:a7qh13$15fb$1@digitaldaemon.com...
>
> "Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:a7gom0$96n$1@digitaldaemon.com...
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:a7gfrs$35e$1@digitaldaemon.com...
> > > I don't see why volatile is that necessary for hardware registers. You
> can
> > > still easilly read a hardware register by setting a pointer to it and
> > going
> > > *p.
> > Sure.  But I am trying, as I thought you were with D, trying to minimize/eliminate the use of pointers in the source code as a major
> source
> > of error.
>
> Pointers are still in D, for the reason that sometimes you just gotta have them.

Sure.

> Minimizing them is a design goal, though.

And a worthy one.


> Also, to access hardware
> registers, you're going to need pointers because there is no way to
specify
> absolute addresses for variables.

Well, you could change that and eliminate one more use of pointers.  I know of at least one language that allows the specification of absolute addresses for variables.  You have to be careful when to allow/implement it, but it seems to work well.  Some versions of the compiler (like the one given to students) just ignore the extra specification, but there are versions (you could use options) to support this.  Another way to do it is to honor the requests but make the addresses program absolute and rely on the linker and other external things like the loader (or Prom/flash) burne to make them truely absolute.

BTW, their syntax is varname type @address


> > > The compiler isn't going to skip the write to it through *p (it's
very,
> > > very hard for a C optimizer to remove dead stores through pointers,
due
> to
> > > the aliasing problem).
> > Again, I am not a compiler designer, but "very very hard" implies that
it
> > isn't impossible and therefore, some future compiler *could* do it and
> thus
> > breaking code as you described the problem above.  :-(
>
> To make it impossible just have the pointer set in a function that the compiler doesn't know about.

Yes, but that is another "work around" that just doesn't seem "natural" Adding extra requirements that the programmer needs to know about in order to "trick" the compiler into doing the right thing are IMNSHO, not the right way to go.

>
> > > Any reads through a pointer are not cached across any
> > > assignments through a pointer, including any function calls (again,
due
> to
> > > the aliasing problem). For example, the second read of *p will not get
> > > cached away:
> > >     x = *p;        // first read
> > >     func();        // call function to prevent caching of pointer
> results
> > >     y = *p;        // second read
> > > func() can simply consist of RET. To do, say, a spin lock on *p:
> > >     while (*p != value)
> > >         func();
> > Oh, that's intuitive!  :-(  Add an extra empty function call in order to prevent the compiler from doing some undesirable optimization.  Uccccch! There has got to be a better way to address the problem than this.  I'm
> not
> > wedded to the "volatile" syntax and certainly not wedded to how C does things.  I was just pointing out, for those who have never done embedded programming, a major reason for that syntax.  If you can come up with a better solution (I guess I don't count the ones you have proposed so far
> to
> > be better.) than I am all for it.
>
> Yeah, I understand it isn't the greatest, but it'll work reliably.

Agreed. I am working toward comming up with "the greatest" solution.  :-)

> I also
> happen to be fond of inline assembler when dealing with hardware <g>.

An affliction that I am afraid is chronic, and probably not curable. :-)  As I believe that the purpose of a high level language is to minimize the use of assembler, I am not so afflicted.  You can always drop to assembler, but that is precisely what we are trying to avoid as much as possible.


> > You have showed such immagination in
> > solving other C/C++ deficiencies that I have reason to hope you can
solve
> > this one elegantly.
>
> Ahem. I'm on to that tactic!

But, based on your next post about "sequential", it seems to have worked :-) (I'll respond to that post there.) That is my goal here.  To promote discussion on variious ways of solving the problems in order for the best one to come out.

--
 - Stephen Fuld
   e-mail address disguised to prevent spam

"Walter" <walter@digitalmars.com> wrote in message news:a7qrji$1bnv$1@digitaldaemon.com...
>
> "Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:a7gom0$96n$1@digitaldaemon.com...
> >> Oh, that's intuitive!  :-(  Add an extra empty function call in order
to
> > prevent the compiler from doing some undesirable optimization.  Uccccch! There has got to be a better way to address the problem than this.  I'm
> not
> > wedded to the "volatile" syntax and certainly not wedded to how C does things.  I was just pointing out, for those who have never done embedded programming, a major reason for that syntax.  If you can come up with a better solution (I guess I don't count the ones you have proposed so far
> to
> > be better.) than I am all for it.  You have showed such immagination in solving other C/C++ deficiencies that I have reason to hope you can
solve
> > this one elegantly.
>
> I did have a thought. How about a keyword "sequence", as in:
>
>     sequence;        // no caching across this keyword
>     x = *p;            // *p is always reloaded
>
> and:
>     x = *p;
>     sequence;        // *p is not cached

I think the fundamental question is whether the "non registerability" should be a property of the variable (that is, "volatile") or of the particular access to the variable (that is, "sequence").  I guess there are two types of situations where this functionality is required, variables shared among multiple threads and physical hardware registers.

For the latter, since we are talking about a direct, one to one relationship between a variable and a particular piece of physical hardware, I think it is clearly a property of the variable itself.

For the former, I guess it it could be considered either.  But in practical terms, since one thread can't know when another thread is going to access the variable, you probably don't want the variable living in a register for any significant length of time, and probably want a simple locking mechanism as well.

So I guess I come down on the side of making it a property of the variable, not the particular access.  I think that will reduce source program size, eliminate the class of bugs that might occur for someone "forgetting" to put in the sequence keyword, etc.

The lock mechanism is a separate issue, but I do believe there should be a defined access to the low cost locks offerred by atomic instructions in most architectures.

--
 - Stephen Fuld
   e-mail address disguised to prevent spam

"Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:a7t4c6$2jfd$1@digitaldaemon.com...

> Well, you could change that and eliminate one more use of pointers.  I
know
> of at least one language that allows the specification of absolute
addresses

Borland Pascal had it. It was great for low-level programming, indeed.

"Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message
news:a7t4ca$2jfd$2@digitaldaemon.com...
<SNIP>
> The lock mechanism is a separate issue, but I do believe there should be a defined access to the low cost locks offerred by atomic instructions in
most
> architectures.
>
> --
>  - Stephen Fuld
>    e-mail address disguised to prevent spam
>

Isn't depending on atomic instructions dangerous?
What about multi-processor systems, where two
atomic instructions might execute simultaneously?


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a7tdf1$2o5m$1@digitaldaemon.com...
> "Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message news:a7t4c6$2jfd$1@digitaldaemon.com...
>
> > Well, you could change that and eliminate one more use of pointers.  I
> know
> > of at least one language that allows the specification of absolute
> addresses
>
> Borland Pascal had it. It was great for low-level programming, indeed.
>

Yeah I loved it!
Also great for addressing BIOS vars and VGA memory
(in the old DOS days)... :)


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a7tf5d$2p0k$1@digitaldaemon.com...
>
> "Stephen Fuld" <s.fuld.pleaseremove@att.net> wrote in message
> news:a7t4ca$2jfd$2@digitaldaemon.com...
> <SNIP>
> > The lock mechanism is a separate issue, but I do believe there should be
a
> > defined access to the low cost locks offerred by atomic instructions in
> most
> > architectures.
> >
> > --
> >  - Stephen Fuld
> >    e-mail address disguised to prevent spam
> >
>
> Isn't depending on atomic instructions dangerous?
> What about multi-processor systems, where two
> atomic instructions might execute simultaneously?

The atomic instructions I was talking about are things like test and set, compare and swap, or atomic fetch-op-store, where the memory is locked for the duration of the instruction.  These are safe in multi-processor systems. Sorry if I confused you.

--
 - Stephen Fuld
   e-mail address disguised to prevent spam



>
>
> --
> Stijn
> OddesE_XYZ@hotmail.com
> http://OddesE.cjb.net
> __________________________________________
> Remove _XYZ from my address when replying by mail
>
>
>