Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #61986 > unrolled thread

Sequence points and commit to memory

Back to article view | Back to comp.lang.c

Contents

  Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-14 11:43 +0100
    Re: Sequence points and commit to memory Richard Heathfield <rjh@cpax.org.uk> - 2015-05-14 12:02 +0100
      Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-14 13:39 +0200
        Re: Sequence points and commit to memory Richard Heathfield <rjh@cpax.org.uk> - 2015-05-14 13:18 +0100
          Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-14 23:11 +0200
    Re: Sequence points and commit to memory Stephen Sprunk <stephen@sprunk.org> - 2015-05-14 09:06 -0500
    Re: Sequence points and commit to memory Siri Cruz <chine.bleu@yahoo.com> - 2015-05-14 08:35 -0700
      Re: Sequence points and commit to memory David Kleinecke <dkleinecke@gmail.com> - 2015-05-14 10:23 -0700
        Re: Sequence points and commit to memory Siri Cruz <chine.bleu@yahoo.com> - 2015-05-14 10:44 -0700
          Re: Sequence points and commit to memory David Kleinecke <dkleinecke@gmail.com> - 2015-05-14 11:09 -0700
            Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-14 12:58 -0700
            Re: Sequence points and commit to memory Morris Dovey <mrdovey@iedu.com> - 2015-05-14 16:31 -0500
              Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-14 17:24 -0700
                Re: Sequence points and commit to memory Morris Dovey <mrdovey@iedu.com> - 2015-05-14 20:18 -0500
                  Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-15 09:34 +0200
                    Re: Sequence points and commit to memory Morris Dovey <mrdovey@iedu.com> - 2015-05-15 10:18 -0500
                    Re: 'register' attribute (was: Sequence points and commit to memory) Morris Dovey <mrdovey@iedu.com> - 2015-05-16 01:26 -0500
                      Re: 'register' attribute David Brown <david.brown@hesbynett.no> - 2015-05-17 00:02 +0200
                        Re: 'register' attribute Morris Dovey <mrdovey@iedu.com> - 2015-05-16 19:29 -0500
              Re: Sequence points and commit to memory David Kleinecke <dkleinecke@gmail.com> - 2015-05-15 09:52 -0700
                Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-15 13:27 -0400
                  Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-15 10:50 -0700
                Re: Sequence points and commit to memory Morris Dovey <mrdovey@iedu.com> - 2015-05-15 12:32 -0500
        Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-14 23:23 +0200
          Re: Sequence points and commit to memory David Kleinecke <dkleinecke@gmail.com> - 2015-05-15 09:42 -0700
            Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-15 13:13 -0400
              Re: Sequence points and commit to memory David Kleinecke <dkleinecke@gmail.com> - 2015-05-16 08:32 -0700
            Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-15 10:35 -0700
            Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-15 11:08 -0700
              Re: Sequence points and commit to memory Robert Wessel <robertwessel2@yahoo.com> - 2015-05-15 16:40 -0500
              Re: Sequence points and commit to memory David Kleinecke <dkleinecke@gmail.com> - 2015-05-16 08:48 -0700
            Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-15 21:46 +0100
              Re: Sequence points and commit to memory David Kleinecke <dkleinecke@gmail.com> - 2015-05-16 08:56 -0700
                Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-16 19:35 +0100
                  Re: Sequence points and commit to memory David Kleinecke <dkleinecke@gmail.com> - 2015-05-18 09:49 -0700
                    Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-19 09:04 +0100
                    Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-19 08:42 -0700
      Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-14 22:00 +0100
        Re: Sequence points and commit to memory Siri Cruz <chine.bleu@yahoo.com> - 2015-05-14 14:26 -0700
          Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-14 22:33 +0100
        Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-14 23:38 +0200
          Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-14 23:04 +0100
            Re: Sequence points and commit to memory Stephen Sprunk <stephen@sprunk.org> - 2015-05-15 13:09 -0500
              Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-15 21:56 +0100
                Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-15 17:30 -0400
                  Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-16 07:51 +0100
                    Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-16 22:10 -0400
                      Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-19 00:25 +0200
                        Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-18 18:55 -0400
                          Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-19 09:10 +0200
                            Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-19 12:05 -0400
                              Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-19 18:42 +0200
                Re: Sequence points and commit to memory Stephen Sprunk <stephen@sprunk.org> - 2015-05-16 16:33 -0500
                  Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-19 00:27 +0200
                    Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-18 19:05 -0400
                      Re: Sequence points and commit to memory glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-19 00:09 +0000
                        Re: Sequence points and commit to memory Richard Heathfield <rjh@cpax.org.uk> - 2015-05-19 01:11 +0100
                          Re: Sequence points and commit to memory Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-23 07:02 -0700
                        Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-18 23:21 -0400
                          Re: Sequence points and commit to memory glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-19 06:25 +0000
                            Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-19 08:58 +0200
                              Re: Sequence points and commit to memory glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-19 23:20 +0000
                                Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-20 12:31 +0200
                            Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-19 12:10 -0400
                              Re: Sequence points and commit to memory glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-19 23:24 +0000
                      Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-19 09:05 +0200
                        Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-19 08:37 -0700
                        Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-19 12:14 -0400
                          Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-19 19:02 +0200
              Re: Sequence points and commit to memory Robert Wessel <robertwessel2@yahoo.com> - 2015-05-15 16:46 -0500
            Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-17 00:20 +0200
              Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-17 18:19 +0100
                Re: Sequence points and commit to memory Philip Lantz <prl@canterey.us> - 2015-05-17 16:11 -0700
                  Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-18 08:30 +0100
                    Re: Sequence points and commit to memory David Kleinecke <dkleinecke@gmail.com> - 2015-05-18 10:31 -0700
                      Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-18 11:11 -0700
                        Re: Sequence points and commit to memory David Kleinecke <dkleinecke@gmail.com> - 2015-05-19 09:37 -0700
                      Re: Sequence points and commit to memory Ian Collins <ian-news@hotmail.com> - 2015-05-19 17:40 +1200
                        Re: Sequence points and commit to memory Morris Dovey <mrdovey@iedu.com> - 2015-05-19 01:31 -0500
                          Re: Sequence points and commit to memory Ian Collins <ian-news@hotmail.com> - 2015-05-19 20:38 +1200
                            Re: Sequence points and commit to memory Morris Dovey <mrdovey@iedu.com> - 2015-05-19 10:50 -0500
                    Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-19 00:46 +0200
                Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-19 00:35 +0200
        Re: Sequence points and commit to memory Robert Wessel <robertwessel2@yahoo.com> - 2015-05-15 16:42 -0500
          Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-16 07:58 +0100
            Re: Sequence points and commit to memory Robert Wessel <robertwessel2@yahoo.com> - 2015-05-16 02:18 -0500
              Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-16 08:36 +0100
                Re: Sequence points and commit to memory Robert Wessel <robertwessel2@yahoo.com> - 2015-05-17 04:31 -0500
                  Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-17 18:24 +0100
                    Re: Sequence points and commit to memory David Brown <david.brown@hesbynett.no> - 2015-05-19 00:55 +0200
    Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-14 11:26 -0700
      Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-14 22:07 +0100
        Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-14 14:22 -0700
          Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-14 22:36 +0100
      Re: Sequence points and commit to memory Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-22 08:16 -0700
        Re: Sequence points and commit to memory Keith Thompson <kst-u@mib.org> - 2015-05-22 11:31 -0700
    Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-15 00:05 -0400
      Re: Sequence points and commit to memory "James Harris" <james.harris.1@gmail.com> - 2015-05-15 22:25 +0100
        Re: Sequence points and commit to memory James Kuyper <jameskuyper@verizon.net> - 2015-05-15 17:56 -0400
    Re: Sequence points and commit to memory Nobody <nobody@nowhere.invalid> - 2015-05-17 10:04 +0100
    Re: Sequence points and commit to memory Tim Rentsch <txr@alumni.caltech.edu> - 2015-05-24 08:11 -0700

Page 1 of 6  [1] 2 3 4 5 6  Next page →

#61986 — Sequence points and commit to memory

I understand that there is a so-called "sequence point" after an 
assignment (taking an assignment as "the expression in an expression 
statement"). As far as what that means, I read: "all side effects of 
previous evaluations shall be complete and no side effects of subsequent 
evaluations shall have taken place."

But does that mean that the value of u will have been updated in memory? 
I guess not because a compiler will normally carry values around in 
registers and only spill them to memory when it has to.

I was looking for guarantees about updates reaching memory so that they 
would be visible to an interrupt handling function. When I speak about 
writes to memory they would not have had to have reached RAM. Storage in 
cache would be OK.

How about:

  u = 0;
  f();

Is u guaranteed to have been written to memory before function f is 
called? Does f need to be in a different translation unit to force prior 
commits to memory (so that pointers to their values are valid)?

James

[toc] | [next] | [standalone]

#61989

On 14/05/15 11:43, James Harris wrote:
> I understand that there is a so-called "sequence point" after an
> assignment (taking an assignment as "the expression in an expression
> statement"). As far as what that means, I read: "all side effects of
> previous evaluations shall be complete and no side effects of subsequent
> evaluations shall have taken place."

Well, the sequence point comes at the semicolon. (There are other places 
where sequence points happen, but the assignment operator is not one of 
them.)

> But does that mean that the value of u will have been updated in memory?

Yes (in the example you show further on in your article).

> I guess not because a compiler will normally carry values around in
> registers and only spill them to memory when it has to.

When it hits a sequence point, it has to.

> I was looking for guarantees about updates reaching memory so that they
> would be visible to an interrupt handling function. When I speak about
> writes to memory they would not have had to have reached RAM. Storage in
> cache would be OK.
>
> How about:
>
>    u = 0;
>    f();
>
> Is u guaranteed to have been written to memory before function f is
> called?

Yes.

> Does f need to be in a different translation unit to force prior
> commits to memory (so that pointers to their values are valid)?

No.


-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#61992

On 14/05/15 13:02, Richard Heathfield wrote:
> On 14/05/15 11:43, James Harris wrote:
>> I understand that there is a so-called "sequence point" after an
>> assignment (taking an assignment as "the expression in an expression
>> statement"). As far as what that means, I read: "all side effects of
>> previous evaluations shall be complete and no side effects of subsequent
>> evaluations shall have taken place."
>
> Well, the sequence point comes at the semicolon. (There are other places
> where sequence points happen, but the assignment operator is not one of
> them.)
>
>> But does that mean that the value of u will have been updated in memory?
>
> Yes (in the example you show further on in your article).

No.

>
>> I guess not because a compiler will normally carry values around in
>> registers and only spill them to memory when it has to.
>
> When it hits a sequence point, it has to.

No.

>
>> I was looking for guarantees about updates reaching memory so that they
>> would be visible to an interrupt handling function. When I speak about
>> writes to memory they would not have had to have reached RAM. Storage in
>> cache would be OK.
>>
>> How about:
>>
>>    u = 0;
>>    f();
>>
>> Is u guaranteed to have been written to memory before function f is
>> called?
>
> Yes.

No.

>
>> Does f need to be in a different translation unit to force prior
>> commits to memory (so that pointers to their values are valid)?
>
> No.
>
>
Not directly relevant.


The reality is a good deal more complex than you are thinking here.

The key to getting this right is to think about what a C program 
actually /means/.  The compiler generates object code that acts as if 
the C source were being run on a C virtual machine, with respect to the 
externally visible inputs, outputs and events.  It only has to match up 
ordering of the /externally/ visible inputs, outputs and events - things 
that are "hidden" within the code can be done in any order, or removed 
altogether if they don't affect external effects.  And the key external 
effects are accesses to volatile variables, calls to functions whose 
definitions are not known to the compiler at the time, and program start 
and stop.

So if you write "u = 0; f();" and the compiler knows the definition of 
f() (and of any functions it calls, recursively), then the compiler can 
quite happily delay writing 0 to u.  If f() writes something else to u, 
then it may /never/ write 0 to u.  If f() reads u, and the compiler is 
inlining f(), then the read can be replaced by a direct 0 (and can 
follow with constant propagation optimisations).

Even if f() is not known to the compiler, but the compiler knows there 
is no legal (in C) way for the function to access u, because u is not 
externally linked and its address does not leak out, then there is no 
requirement to store u before calling f().


There are several ways to make sure the value of u is updated.  If you 
are using an OS, you may have OS-specific methods, such as the 
"barrier()" function/macro in Linux which forces uncommitted writes to 
be written and blocks pre-emptive reads.  You should also use your OS's 
techniques for passing data between main code and interrupt code.

For non-OS code, "volatile" is the key technique.  If u is "volatile", 
then you are telling your compiler that its value may change, or may be 
read, by something outside the control and knowledge of the compiler. 
In this case, "u = 0" /will/ be executed immediately, and the value 
stored in memory (or cache, buffers, etc.).  Note that it is the access 
that is volatile, rather than the variable itself - a "volatile 
variable" is merely a variable whose accesses are always volatile.

Another method is to make your own barriers.  A common implementation 
(for gcc, or compilers that support gcc inline assembly) is:

// Compiler-only memory barrier
static inline void compilerBarrier(void) {
         asm volatile("" ::: "memory");
}


Then the sequence

u = 0;
compilerBarrier();
f();

will ensure the write to u is committed before f() is called.  And don't 
forget the compilerBarrier() before /reading/ u.


You might also find something useful in the new C11 atomic stuff.

[toc] | [prev] | [next] | [standalone]

#61994

On 14/05/15 12:39, David Brown wrote:
> On 14/05/15 13:02, Richard Heathfield wrote:
>> On 14/05/15 11:43, James Harris wrote:
>>> I understand that there is a so-called "sequence point" after an
>>> assignment (taking an assignment as "the expression in an expression
>>> statement"). As far as what that means, I read: "all side effects of
>>> previous evaluations shall be complete and no side effects of subsequent
>>> evaluations shall have taken place."
>>
>> Well, the sequence point comes at the semicolon. (There are other places
>> where sequence points happen, but the assignment operator is not one of
>> them.)
>>
>>> But does that mean that the value of u will have been updated in memory?
>>
>> Yes (in the example you show further on in your article).
>
> No.

Yes, if u is not volatile. :-)

Good spot. I'd forgotten about volatile.

<snip>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#62023

On 14/05/15 14:18, Richard Heathfield wrote:
> On 14/05/15 12:39, David Brown wrote:
>> On 14/05/15 13:02, Richard Heathfield wrote:
>>> On 14/05/15 11:43, James Harris wrote:
>>>> I understand that there is a so-called "sequence point" after an
>>>> assignment (taking an assignment as "the expression in an expression
>>>> statement"). As far as what that means, I read: "all side effects of
>>>> previous evaluations shall be complete and no side effects of
>>>> subsequent
>>>> evaluations shall have taken place."
>>>
>>> Well, the sequence point comes at the semicolon. (There are other places
>>> where sequence points happen, but the assignment operator is not one of
>>> them.)
>>>
>>>> But does that mean that the value of u will have been updated in
>>>> memory?
>>>
>>> Yes (in the example you show further on in your article).
>>
>> No.
>
> Yes, if u is not volatile. :-)
>
> Good spot. I'd forgotten about volatile.
>

Most C programmers live without ever seeing "volatile" - you are usually 
best with OS-specific methods of handling memory that needs special 
treatment.  The trouble with "volatile" is that it is often unnecessary, 
but even more often it is not powerful enough (it tells you nothing 
about how data is written to memory, merely how the compiler will tell 
the cpu to write it.  Modern cpus can add endless complications on top 
of what the compiler does).

But for small-system embedded programmers like myself, a good 
understanding of "volatile" (and memory barriers) is essential.

[toc] | [prev] | [next] | [standalone]

#61998

On 14-May-15 05:43, James Harris wrote:
> I was looking for guarantees about updates reaching memory so that
> they would be visible to an interrupt handling function. When I speak
> about writes to memory they would not have had to have reached RAM.
> Storage in cache would be OK.
> 
> How about:
> 
> u = 0;
> f();
> 
> Is u guaranteed to have been written to memory before function f is 
> called? Does f need to be in a different translation unit to force
> prior commits to memory (so that pointers to their values are
> valid)?

There is no guarantee that u will _ever_ be written to memory, or even
that a specific location in memory is reserved to hold it!

You are forgetting what is probably the single most important part in
the C standard: the implementation can do whatever it wants to do under
the hood as long as a conforming program can't tell the difference vs
what the Standard prescribes.  This is known as the "as if" rule.

One of the consequences of this is that when you invoke Undefined
Behavior, you may end up seeing things that do _not_ behave as you
expect them to, such as a variable not being updated in RAM after you
assign a value to it, even after a sequence point.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

[toc] | [prev] | [next] | [standalone]

#62001

In article <mj1u70$r5d$1@dont-email.me>,
 "James Harris" <james.harris.1@gmail.com> wrote:

> How about:
> 
>   u = 0;
>   f();
> 
> Is u guaranteed to have been written to memory before function f is 

No. There's nothing in the above that exposes the address of u to f, so f has no 
legitmate way to know about u.

    extern int *v; v = &u;
    u = 0;
    f();

Now the f might have access to the address of u. The compiler would need to have 
the implementation of f at hand to see if uses any (extern int*), all the places 
those are used, etc, to safely determine that f still does not have access to u.

MIPS used its loader as a compiler so that it had the entire program text 
available. It could then do this kind of global analysis.

> called? Does f need to be in a different translation unit to force prior 
> commits to memory (so that pointers to their values are valid)?

If you never take the address of u, it does not need memory allocated; 
equivalently if you declare register int u, it does not need memory allocated. 


volatile int u means that no assignment nor load can be redundant. The compiler 
must assume some unknown process can alter u asynchronously anywhere even in the 
execution of any instruction except an atomic load or store.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
When is a Kenyan not a Kenyan? When he's a Canadian.
That's People's Commissioner Siri Cruz now. Punch!

[toc] | [prev] | [next] | [standalone]

#62004

On Thursday, May 14, 2015 at 8:35:28 AM UTC-7, Siri Cruz wrote:
> In article <mj1u70$r5d$1@dont-email.me>,
>  "James Harris" <james.harris.1@gmail.com> wrote:
> 
> > How about:
> > 
> >   u = 0;
> >   f();
> > 
> > Is u guaranteed to have been written to memory before function f is 
> 
> No. There's nothing in the above that exposes the address of u to f, so f has no 
> legitmate way to know about u.
> 
>     extern int *v; v = &u;
>     u = 0;
>     f();
> 
> Now the f might have access to the address of u. The compiler would need to have 
> the implementation of f at hand to see if uses any (extern int*), all the places 
> those are used, etc, to safely determine that f still does not have access to u.
> 
> MIPS used its loader as a compiler so that it had the entire program text 
> available. It could then do this kind of global analysis.
> 
> > called? Does f need to be in a different translation unit to force prior 
> > commits to memory (so that pointers to their values are valid)?
> 
> If you never take the address of u, it does not need memory allocated; 
> equivalently if you declare register int u, it does not need memory allocated. 
> 
> 
> volatile int u means that no assignment nor load can be redundant. The compiler 
> must assume some unknown process can alter u asynchronously anywhere even in the 
> execution of any instruction except an atomic load or store.
> 
> -- 
> :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
> 'I desire mercy, not sacrifice.'
> When is a Kenyan not a Kenyan? When he's a Canadian.
> That's People's Commissioner Siri Cruz now. Punch!

Is it proper to assume that the C virtual machine has registers?

Computers have been built (perhaps still are) that do not have any kind
of cache that can be called registers. 

In such a machine the original question vanishes (- is trivial). 

It seems to me that what is involved here is a question about optimization
of the output code on particular hardware. The Standard is attempting to 
place limitations on the optimization. No harm in that but perhaps specific
rules are not needed in light of the black box rule (the output code must
be the same for any optimization).

[toc] | [prev] | [next] | [standalone]

#62010

In article <928a9f76-7417-4e84-81b1-a92f71517ab0@googlegroups.com>,
 David Kleinecke <dkleinecke@gmail.com> wrote:

> Is it proper to assume that the C virtual machine has registers?

You can't take the address of a register variable, regardless of how the 
variable is implemented. The compiler is free to treat register variables 
exactly like auto except it should reject taking the address.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
When is a Kenyan not a Kenyan? When he's a Canadian.
That's People's Commissioner Siri Cruz now. Punch!

[toc] | [prev] | [next] | [standalone]

#62013

On Thursday, May 14, 2015 at 10:44:54 AM UTC-7, Siri Cruz wrote:
> In article <928a9f76-7417-4e84-81b1-a92f71517ab0@googlegroups.com>,
>  David Kleinecke <dkleinecke@gmail.com> wrote:
> 
> > Is it proper to assume that the C virtual machine has registers?
> 
> You can't take the address of a register variable, regardless of how the 
> variable is implemented. The compiler is free to treat register variables 
> exactly like auto except it should reject taking the address.
> 
> -- 
> :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
> 'I desire mercy, not sacrifice.'
> When is a Kenyan not a Kenyan? When he's a Canadian.
> That's People's Commissioner Siri Cruz now. Punch!

"Register" only has optional meaning. If a machine has no actual registers
all declaring a variable as "register" means is that you are forbidding
yourself from taking its address etc. This is something I assume - if there
are no real registers - you would not want to do. 

So if you do use the "register" storage class you are making your program
less portable (surely not by a great deal but somewhat).

Fortunately I haven't seen any software for years (except stuff I dredge
up from the archives) that uses "register" (or "auto").

[toc] | [prev] | [next] | [standalone]

#62016

David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> "Register" only has optional meaning. If a machine has no actual registers
> all declaring a variable as "register" means is that you are forbidding
> yourself from taking its address etc.

Right.

>                                       This is something I assume - if there
> are no real registers - you would not want to do. 

Why not?  There's probably not much advantage in using the "register"
keyword (even for machines that do have registers), but it should be
mostly harmless.

The standard's description of "register" doesn't even mention CPU
registers; it merely "suggests that access to the object be as fast as
possible".  That could have some effect even on a registerless CPU.  Or
it could have no effect.

> So if you do use the "register" storage class you are making your program
> less portable (surely not by a great deal but somewhat).

No, it's no less portable; why would it be?

"register" is intended as a way for the programmer to give information
to the compiler about how an object is used.  If that information is
incorrect it might hurt performance, but it shouldn't affect
correctness.

> Fortunately I haven't seen any software for years (except stuff I dredge
> up from the archives) that uses "register" (or "auto").

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#62027

On 5/14/15 1:09 PM, David Kleinecke wrote:
> Fortunately I haven't seen any software for years (except stuff I
> dredge up from the archives) that uses "register" (or "auto").

Current example at http://www.iedu.com/Solar/LENR/Code.html = scroll
down to qram.c and see QuadRAM() function which converts a linear memory
address to a bank-switched address in an embedded system.

It can be a really helpful feature. :-)

-- 
Morris Dovey
http://www.iedu.com/Solar

[toc] | [prev] | [next] | [standalone]

#62032

Morris Dovey <mrdovey@iedu.com> writes:
> On 5/14/15 1:09 PM, David Kleinecke wrote:
>> Fortunately I haven't seen any software for years (except stuff I
>> dredge up from the archives) that uses "register" (or "auto").
>
> Current example at http://www.iedu.com/Solar/LENR/Code.html = scroll
> down to qram.c and see QuadRAM() function which converts a linear memory
> address to a bank-switched address in an embedded system.
>
> It can be a really helpful feature. :-)

Does your compiler generate better code for that function than it
would if you just deleted all the "register" keywords?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#62033

On 5/14/15 7:24 PM, Keith Thompson wrote:
> Morris Dovey <mrdovey@iedu.com> writes:
>> On 5/14/15 1:09 PM, David Kleinecke wrote:
>>> Fortunately I haven't seen any software for years (except stuff I
>>> dredge up from the archives) that uses "register" (or "auto").
>>
>> Current example at http://www.iedu.com/Solar/LENR/Code.html =
>> scroll down to qram.c and see QuadRAM() function which converts a
>> linear memory address to a bank-switched address in an embedded
>> system.
>>
>> It can be a really helpful feature. :-)
>
> Does your compiler generate better code for that function than it
> would if you just deleted all the "register" keywords?

Somewhat to my surprise, it does - and the code was better with an -O2
than with -O1 or -O3 optimization parameters. You may have noticed that
I put a remark in the prolog to produce an assembly listing so I could
keep an eye this "interesting" behavior. :-)

A delayed comment on use of the 'auto' attribute keyword - since auto is
the default, specifying it probably isn’t ever necessary - but when I
write recursive functions, I often explicitly specify automatic
variables as 'auto' more as a reminder to myself of my thinking at the
time I wrote the code than as telling the compiler what to do.

-- 
Morris Dovey
http://www.iedu.com/Solar

[toc] | [prev] | [next] | [standalone]

#62037

On 15/05/15 03:18, Morris Dovey wrote:
> On 5/14/15 7:24 PM, Keith Thompson wrote:
>> Morris Dovey <mrdovey@iedu.com> writes:
>>> On 5/14/15 1:09 PM, David Kleinecke wrote:
>>>> Fortunately I haven't seen any software for years (except stuff I
>>>> dredge up from the archives) that uses "register" (or "auto").
>>>
>>> Current example at http://www.iedu.com/Solar/LENR/Code.html =
>>> scroll down to qram.c and see QuadRAM() function which converts a
>>> linear memory address to a bank-switched address in an embedded
>>> system.
>>>
>>> It can be a really helpful feature. :-)
>>
>> Does your compiler generate better code for that function than it
>> would if you just deleted all the "register" keywords?
> 
> Somewhat to my surprise, it does - and the code was better with an -O2
> than with -O1 or -O3 optimization parameters. You may have noticed that
> I put a remark in the prolog to produce an assembly listing so I could
> keep an eye this "interesting" behavior. :-)

gcc ignores the "register" keyword entirely except in two circumstances
- you are compiling without optimisation (in which case only "register"
variables stay in a register rather than in the stack frame), or as part
of the "register asm" extension to force a register to be used for a
specific variable.  If you think using "register" helps with gcc, you
are either using a truly ancient gcc (and I think that would be prior to
the gcc support for the AVR), or you are mistaken.

Different code can be generated for -O1, -O2 and -O3, and while there is
a tendency towards faster code with higher optimisation level numbers,
there are always types of code that happen to give faster results with
lower levels.  In particular, -O3 is slower on many systems with
instruction cache or "loop shortcut" cpu hardware.  The common practice
for small embedded systems is to use "-Os", which gives a balance
between performance and code size that works well for many uses - but of
course there are situations where different options are preferred for
various reasons.

Also note that the AVR is a rather specialised target but there is very
limited developer resources working on the backend - avr-gcc does not
always generate ideal code automatically, but can often be persuaded
with careful use of flags.  For example, some code is better with
"-fsplit-wide-types", other code is worse.  Automatic inlining choices
are often not ideal for the AVR, especially on all but the very latest
versions of gcc, so manual choice using attributes can make a big
difference.  And sometimes the code quality is significantly different
between different avr-gcc versions.


One thing I note about your code is your use of unsized types (unsigned
long, etc.) - your code would be neater, clearer, and more robust if you
used the standard sized types (uint8_t, uint16_t, etc.).


> 
> A delayed comment on use of the 'auto' attribute keyword - since auto is
> the default, specifying it probably isn’t ever necessary - but when I
> write recursive functions, I often explicitly specify automatic
> variables as 'auto' more as a reminder to myself of my thinking at the
> time I wrote the code than as telling the compiler what to do.
> 

That is a rather bad idea, if you are looking towards the future.  The
"auto" specifier is so rarely used in real-world code that C++ has
completely changed the meaning of the keyword in C++11.  Whether this
feature makes it into C remains to be seen (it would be useful in some C
code, but the advantage is not nearly as high as in C++), but gcc
already has a "__auto_type" extension in C.  So it certainly does not
make sense to resurrect a keyword that has seen little use for decades,
and may cause trouble in the future.

[toc] | [prev] | [next] | [standalone]

#62043

On 5/15/15 2:34 AM, David Brown wrote:
> On 15/05/15 03:18, Morris Dovey wrote:
>> On 5/14/15 7:24 PM, Keith Thompson wrote:
>>> Morris Dovey <mrdovey@iedu.com> writes:
>>>> On 5/14/15 1:09 PM, David Kleinecke wrote:
>>>>> Fortunately I haven't seen any software for years (except
>>>>> stuff I dredge up from the archives) that uses "register" (or
>>>>> "auto").
>>>>
>>>> Current example at http://www.iedu.com/Solar/LENR/Code.html =
>>>> scroll down to qram.c and see QuadRAM() function which converts
>>>> a linear memory address to a bank-switched address in an
>>>> embedded system.
>>>>
>>>> It can be a really helpful feature. :-)
>>>
>>> Does your compiler generate better code for that function than
>>> it would if you just deleted all the "register" keywords?

I'll give that a try when I revisit the code - you've made me curious.
If there's no difference, I'll smile at myself and just leave 'em out.

>> Somewhat to my surprise, it does - and the code was better with an
>> -O2 than with -O1 or -O3 optimization parameters. You may have
>> noticed that I put a remark in the prolog to produce an assembly
>> listing so I could keep an eye this "interesting" behavior. :-)
>
> gcc ignores the "register" keyword entirely except in two
> circumstances - you are compiling without optimisation (in which case
> only "register" variables stay in a register rather than in the stack
> frame), or as part of the "register asm" extension to force a
> register to be used for a specific variable.  If you think using
> "register" helps with gcc, you are either using a truly ancient gcc
> (and I think that would be prior to the gcc support for the AVR), or
> you are mistaken.

I could easily be mistaken and it's entirely possible that the
optimization option chosen (alone) caused the compiler to produce the
preferred behavior. FWIW, it reports that it's version 4.3.3

> Different code can be generated for -O1, -O2 and -O3, and while there
> is a tendency towards faster code with higher optimisation level
> numbers, there are always types of code that happen to give faster
> results with lower levels.  In particular, -O3 is slower on many
> systems with instruction cache or "loop shortcut" cpu hardware.  The
> common practice for small embedded systems is to use "-Os", which
> gives a balance between performance and code size that works well for
> many uses - but of course there are situations where different
> options are preferred for various reasons.

This application isn't particularly demanding in terms of either speed
or code size, but I added a 512KB static RAM for data logging during the
development and testing process. My intent here was to minimize the
impact of writing that data (it'll only be read out and transmitted
after the controlled process has been shut down).

> Also note that the AVR is a rather specialised target but there is
> very limited developer resources working on the backend - avr-gcc
> does not always generate ideal code automatically, but can often be
> persuaded with careful use of flags.  For example, some code is
> better with "-fsplit-wide-types", other code is worse.  Automatic
> inlining choices are often not ideal for the AVR, especially on all
> but the very latest versions of gcc, so manual choice using
> attributes can make a big difference.  And sometimes the code quality
> is significantly different between different avr-gcc versions.

As long as the code generated is true to the C logic, I have the luxury
of not caring (for the reasons above). Once I've established operating
parameters for the process, much of the code will be eliminated.

> One thing I note about your code is your use of unsized types
> (unsigned long, etc.) - your code would be neater, clearer, and more
> robust if you used the standard sized types (uint8_t, uint16_t,
> etc.).

I thought about that, but given that the plan is to go with the current
CPU and toolset and that variable sizes are fixed within this context, I
don't see that neatness, clarity, or robustness are affected. If someone
wants to port the application 'as is' to a different context, they'll
probably face other (more significant) challenges.

>> A delayed comment on use of the 'auto' attribute keyword - since
>> auto is the default, specifying it probably isn’t ever necessary -
>> but when I write recursive functions, I often explicitly specify
>> automatic variables as 'auto' more as a reminder to myself of my
>> thinking at the time I wrote the code than as telling the compiler
>> what to do.
>>
>
> That is a rather bad idea, if you are looking towards the future.
> The "auto" specifier is so rarely used in real-world code that C++
> has completely changed the meaning of the keyword in C++11.  Whether
> this feature makes it into C remains to be seen (it would be useful
> in some C code, but the advantage is not nearly as high as in C++),
> but gcc already has a "__auto_type" extension in C.  So it certainly
> does not make sense to resurrect a keyword that has seen little use
> for decades, and may cause trouble in the future.

Possibly so, but I’ve been 'resurrecting' that particular keyword on a
fairly regular basis since the mid-eighties, and because I prefer 'auto'
to '/*auto*/' as a visual cue, I'll probably keep on until C compilers
change - and even then I'll keep on not caring what the C++ folks do to
their language. :-)

-- 
Morris Dovey
http://www.iedu.com/Solar

[toc] | [prev] | [next] | [standalone]

#62096 — Re: 'register' attribute (was: Sequence points and commit to memory)

On 5/15/15 2:34 AM, David Brown wrote:

> gcc ignores the "register" keyword entirely except in two circumstances
> - you are compiling without optimisation (in which case only "register"
> variables stay in a register rather than in the stack frame), or as part
> of the "register asm" extension to force a register to be used for a
> specific variable.  If you think using "register" helps with gcc, you
> are either using a truly ancient gcc (and I think that would be prior to
> the gcc support for the AVR), or you are mistaken.

I just compiled the function twice - once with the 'register' 
specification in place, and again without. Both compilations produced 
the same assembler listings, so you are correct that the specification 
wasn't needed and I /was/ mistaken when I thought its use might have a 
beneficial effect.

I was pleased to see that the compiler would give me exactly what I 
wanted without my even having to ask - I wish it would do that more 
often! :-)

-- 
Morris Dovey
http://www.iedu.com/Solar

[toc] | [prev] | [next] | [standalone]

#62131 — Re: 'register' attribute

On 16/05/15 08:26, Morris Dovey wrote:
> On 5/15/15 2:34 AM, David Brown wrote:
>
>> gcc ignores the "register" keyword entirely except in two circumstances
>> - you are compiling without optimisation (in which case only "register"
>> variables stay in a register rather than in the stack frame), or as part
>> of the "register asm" extension to force a register to be used for a
>> specific variable.  If you think using "register" helps with gcc, you
>> are either using a truly ancient gcc (and I think that would be prior to
>> the gcc support for the AVR), or you are mistaken.
>
> I just compiled the function twice - once with the 'register'
> specification in place, and again without. Both compilations produced
> the same assembler listings, so you are correct that the specification
> wasn't needed and I /was/ mistaken when I thought its use might have a
> beneficial effect.
>
> I was pleased to see that the compiler would give me exactly what I
> wanted without my even having to ask - I wish it would do that more
> often! :-)
>

Thanks for posting that follow-up - Usenet is quick to let a person know 
when they get something wrong, but it's rare to get confirmation when 
one writes something that is correct!

[toc] | [prev] | [next] | [standalone]

#62137 — Re: 'register' attribute

On 5/16/15 5:02 PM, David Brown wrote:

> Thanks for posting that follow-up - Usenet is quick to let a person know
> when they get something wrong, but it's rare to get confirmation when
> one writes something that is correct!

For me, peer reviews - here and elsewhere - have been a series of gifts 
that just keep on giving...

...and I’d much rather be corrected here than embarrassed elsewhere. :-)

-- 
Morris Dovey
http://www.iedu.com/Solar

[toc] | [prev] | [next] | [standalone]

#62049

On Thursday, May 14, 2015 at 2:31:31 PM UTC-7, Morris Dovey wrote:
> On 5/14/15 1:09 PM, David Kleinecke wrote:
> > Fortunately I haven't seen any software for years (except stuff I
> > dredge up from the archives) that uses "register" (or "auto").
> 
> Current example at http://www.iedu.com/Solar/LENR/Code.html = scroll
> down to qram.c and see QuadRAM() function which converts a linear memory
> address to a bank-switched address in an embedded system.
> 
> It can be a really helpful feature. :-)
> 
> -- 
> Morris Dovey
> http://www.iedu.com/Solar

Now I have seen some recent code using "register". But wouldn't the code
give the same result without the "register"s ?

I assume there must be some efficiency gain or you wouldn't have coded
it that way. But isn't that gain an artifact of your compiler and your
hardware ?

[toc] | [prev] | [next] | [standalone]

Page 1 of 6  [1] 2 3 4 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web