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

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

Re: who invented static?

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: who invented static? Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-12 12:30 -0700
    Re: who invented static? David Brown <david.brown@hesbynett.no> - 2015-09-13 15:48 +0200
      Re: who invented static? supercat@casperkitty.com - 2015-09-29 09:04 -0700
        Re: who invented static? Keith Thompson <kst-u@mib.org> - 2015-09-29 09:18 -0700
          Re: who invented static? supercat@casperkitty.com - 2015-09-29 09:57 -0700

#70375 — Re: who invented static?

David Brown <david.brown@hesbynett.no> writes:

> On 07/09/15 03:59, Tim Rentsch wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 30/08/15 18:18, James Kuyper wrote:
>>>> On 08/30/2015 10:56 AM, David Brown wrote:
>>>>> On 29/08/15 23:08, James Kuyper wrote:
>>>>>
>>>>>> The following use of "static" is new in C99, and can only occur in the
>>>>>> leading dimension of a function parameter declared as an array:
>>>>>> "If the keyword static also appears within the [ and ] of the array type
>>>>>> derivation, then for each call to the function, the value of the
>>>>>> corresponding actual argument shall provide access to the first element
>>>>>> of an array with at least as many elements as specified by the size
>>>>>> expression."  6.7.6.3p7
>>>>>>
>>>>>> This obviously should have no counterpart in K&R C.
>>>>>
>>>>> This last use of "static" is completely new to me.  I can see the
>>>>> corresponding paragraph in the C11 standards (since that's the one I
>>>>> have handy), but I can't figure out what it means or what it is for.
>>
>> It's pretty disappointing that you haven't gotten better replies
>> to your query on this.  The replies I've seen aren't very helpful
>> and get several things wrong.  Let's see if we can do a little
>> better here.
>
> I'm ready to take notes.

I'm following up here after posting my downstream response
correcting the mistake I made.  I am not repeating that but there
are some other comments that may be useful.

>> First, the point of using 'static' in this way is to allow some
>> optimizations to take place that wouldn't be allowed otherwise.
>> If we have a function definition like this
>>
>>     void
>>     foo( int x[ static 100 ] ){
>>         ...
>>     }
>>
>> then when compiling foo() the compiler is allowed to assume
>> that the pointer 'x' (which is a pointer, because of rules
>> about function parameter types) points to an array with at
>> least 100 elements.  That proviso enables the code to, eg,
>> initiate some prefetching if that seems like a good thing to
>> do.
>
> I assume that as well as optimising here, the compiler can also
> use the information for extra checking.  (However I am a little
> disappointed that a quick test with gcc 4.9 does not seem to give
> any warnings when this foo is called with an array of less than
> 100.)

There are two problems with the idea that using the 'static'
attribute this way is (even partly) for compile-time error
reporting.  One, because the 'static' can be there on a
definition but not on a declaration, there is no guarantee that
the call site knows to do the check.  Two, like most conditions
that depend on run-time values, what we're interested in cannot
be checked in the general case.  In all such cases (AFAIAA), the
C standard relegates these to undefined behavior, leaving the
question of any compile-time diagnostics as a QOI matter, not
part of the official language definition.  IMO this choice is
the right decision for C (and I prefer not to consider the
question more generally, at least as far as comp.lang.c goes).

>> Second, using 'static' in this way resembles how 'restrict' works
>> with pointer parameters.  The 'static'-ness of the array is not
>> part of the type of the function, and it doesn't have to be the
>> same in declarations as it is in the definition.  Normally any
>> functions defined with this use of 'static' will also have
>> 'static' in their declarations, but doing that is really just for
>> documentation, not anything else.
>
> I am a big fan of such documentation - and I am very strict about
> declarations and definitions matching exactly (stricter than the
> compiler requires).

I agree everything should be in sync.  My preference, when
possible, is to auto-generate the appropriate declarations based
on the corresponding definitions.  If you can get other people
to buy into that, I find it enormously effective in terms of
both productivity and confidence in the result.

>> Third, what happens with such 'static' parameters when compiling
>> calls to the function is analogous to compiling calls to
>> functions whose parameters have 'restrict' qualifiers.  It
>> doesn't imply any extra checking or constraint validation.  (Of
>> course implementations are free to do extra checking if they
>> want, but none is required.)  What using 'static' does is
>> impose an additional /un/checked requirement that any actual
>> argument have at least that many elements;  not meeting that
>> requirement makes the call be undefined behavior.
>
> Fair enough.
>
> It is nice if the compiler (or possibly other static error
> checkers) can check it.

Any diagnostic of this sort (ie, which is undecidable in the
general case) comes with problems - false positives, false
negatives, or possibly both.  Also, something that may not
have occured to you, the array bound after the 'static' might
not be a constant.  C99 has variable length arrays, which
means that this

    int
    foo( int n, int v[ static n ] ){
        ...
    }

is legal.  Cases like this are much harder to check.

I sympathize with your desire to have diagnostics produced, where
possible.  But this is a QOI concern, not a language concern, and
ANSI/ISO made a deliberate choice to not address QOI matters in
the C standard.  Because of that, it doesn't surprise me, or
disappoint me, that the possibility of doing such a check for
'static' parameters was ignored in defining the C language.

>> Incidentally, note that the length parameter is also not part of
>> the parameter type, and hence may be different between a function 
>> declaration and its definition.  Thus we might have
>>
>>     int foo( int x[ static 200 ] );
>>
>>     ...
>>
>>     int
>>     foo( int x[ static 100 ] ){
>>         ...
>>     }
>>
>> which the Standard allows.  What I believe is true in such
>> cases is that both conditions must be met, ie, the larger
>> value is the one that the compiler may assume.  However
>> the Standard is not completely clear on the matter, so for
>> safety the different values should all agree (and probably
>> expect the value on the function /definition/ to take
>> precedence, although again the Standard isn't completely
>> clear on the matter).
>
> All in all, it sounds like a nice idea, but a little disappointing
> in practice.  I would have preferred the standards (and compiler)
> to be a lot stricter in checking such things.

I explained above why the Standard doesn't address it.  As for
compilers, of course they could, but I expect there isn't much
call to do so, especially since there is no guarantee that the
declarations used match the definitions.

> I can understand
> that for backward compatibility, and the way arrays are handled
> and passed in C, that it is hard for the compiler to enforce or
> assume anything about array parameters that are not declared with
> this "static".  But I had hoped that it could do more with the
> added "static".

The problem is undecidable.  Anything that might be done is
a compromise that some people will be happy with and others
will not.  Unless the user community cries out for something
I don't think anything will be done, especially since the
problem is not just undecidable but difficult to do even
fairly well.  I believe the perception is that the ROI is
just not very high.

> As far as I can tell, the explicit undefined behaviour gives the
> compiler a freer hand for optimisation, and that's about it.

Yes, that is it, exactly it!

> (Compilers /could/ implement a little more static error checking,
> but extrapolating wildly from my sample of 1 test, they apparently
> don't do so.  Perhaps it's simply because this use of "static" is
> not common, so it is not a feature that the gcc folk have
> implemented.)

And that it is hard to do well.

> As for documentation - and therefore "manual" enforcement, I don't
> see that the use of "static" adds anything, at least for my own
> code.  If I declare a function to have a parameter "int x[100]",
> then it is clear to me that this function wants an array of at
> least 100 int's.  The "static" is superfluous from the
> documentation viewpoint.

I think you might want to re-think this position.  By way of
analogy, there's a difference between saying "I'm not going
to drive faster than 35 miles per hour" and saying "I'm not
going to drive faster than 35 miles per hour, and if I do
I agree to pay you as much money as you ask for."  Without
the 'static', there may be some cases, eg based on the values
of other parameters, that are still okay.  With the 'static',
any transgression is irredeemable.  You may choose not to
make these kinds of distinctions, but other people might,
and IMO it is worth keeping that in mind.

> [here was the part that I already addressed]
>
>>> Is this a use of "static" that you have seen in real code?  Is
>>> it used much?
>>
>> Now that you know what it's for, especially with your general
>> concerns for performance, I expect you will finds lots of
>> occasions where it might be useful.
>
> I don't actually pass array parameters around that much, and
> when I do they are often part of a struct anyway.

This statement surprised me.  Do you mean you hardly ever
pass pointer values as function parameters?  Or types
like 'char *'?  Both of these cases have some potential
benefit using 'static'.

> And while
> performance and optimisation opportunities are often a concern
> (smaller and faster code can mean smaller and cheaper
> microcontrollers, or lower power or less electrical noise), I
> see it as unlikely that this "static" qualifier will actually
> lead to faster code on the types of cpus and with the types of
> code that I use.  Still, I am always on the lookout for new
> tools in the toolbox, especially if it can (in theory at least)
> lead to more precise specification and more static error
> analysis.

A pointer parameter declared like 'T x[ static 1 ]' is one that
the compiler may assume is non-null, which may very well help
code generation even on very low-end CPU's.  (Disclaimer:  I
am certainly not an expect on optimization, but I see gcc do
some amazing things based on such "facts", so it seems fair
to say that the scenario is at least plausible.)

[toc] | [next] | [standalone]

#70412

On 12/09/15 21:30, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 07/09/15 03:59, Tim Rentsch wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 30/08/15 18:18, James Kuyper wrote:
>>>>> On 08/30/2015 10:56 AM, David Brown wrote:
>>>>>> On 29/08/15 23:08, James Kuyper wrote:
>>>>>>
>>>>>>> The following use of "static" is new in C99, and can only occur in the
>>>>>>> leading dimension of a function parameter declared as an array:
>>>>>>> "If the keyword static also appears within the [ and ] of the array type
>>>>>>> derivation, then for each call to the function, the value of the
>>>>>>> corresponding actual argument shall provide access to the first element
>>>>>>> of an array with at least as many elements as specified by the size
>>>>>>> expression."  6.7.6.3p7
>>>>>>>
>>>>>>> This obviously should have no counterpart in K&R C.
>>>>>>
>>>>>> This last use of "static" is completely new to me.  I can see the
>>>>>> corresponding paragraph in the C11 standards (since that's the one I
>>>>>> have handy), but I can't figure out what it means or what it is for.
>>>
>>> It's pretty disappointing that you haven't gotten better replies
>>> to your query on this.  The replies I've seen aren't very helpful
>>> and get several things wrong.  Let's see if we can do a little
>>> better here.
>>
>> I'm ready to take notes.
>
> I'm following up here after posting my downstream response
> correcting the mistake I made.  I am not repeating that but there
> are some other comments that may be useful.
>
>>> First, the point of using 'static' in this way is to allow some
>>> optimizations to take place that wouldn't be allowed otherwise.
>>> If we have a function definition like this
>>>
>>>      void
>>>      foo( int x[ static 100 ] ){
>>>          ...
>>>      }
>>>
>>> then when compiling foo() the compiler is allowed to assume
>>> that the pointer 'x' (which is a pointer, because of rules
>>> about function parameter types) points to an array with at
>>> least 100 elements.  That proviso enables the code to, eg,
>>> initiate some prefetching if that seems like a good thing to
>>> do.
>>
>> I assume that as well as optimising here, the compiler can also
>> use the information for extra checking.  (However I am a little
>> disappointed that a quick test with gcc 4.9 does not seem to give
>> any warnings when this foo is called with an array of less than
>> 100.)
>
> There are two problems with the idea that using the 'static'
> attribute this way is (even partly) for compile-time error
> reporting.  One, because the 'static' can be there on a
> definition but not on a declaration, there is no guarantee that
> the call site knows to do the check.

Agreed.  I think this is a major flaw in the way this static attribute 
was introduced, and means it loses much of its potential benefits.  But 
compilers (and programmers) have to live with what the standards say.

Still, a compiler could warn (when the appropriate flag enabled it) for 
cases that it /could/ see - and also for inconsistencies between the 
definition and declaration(s).

>  Two, like most conditions
> that depend on run-time values, what we're interested in cannot
> be checked in the general case.

Also agreed.  But being unable to warn in the general case does not mean 
a compiler cannot warn in specific cases when information is available.

For a normal array, compilers cannot in general see if you are accessing 
them outside their bounds - but compilers /can/ (and recent versions of 
gcc do) warn if it can see that code definitely accesses them outside 
there bounds.

So being unable to identify problems in the general case is not an 
excuse for not warning about bad uses of "static" function parameters.

(On the other hand, lack of time, money, volunteers, etc., is of course 
a perfectly good excuse for it - especially for a relatively little-used 
feature.)

>  In all such cases (AFAIAA), the
> C standard relegates these to undefined behavior, leaving the
> question of any compile-time diagnostics as a QOI matter, not
> part of the official language definition.  IMO this choice is
> the right decision for C (and I prefer not to consider the
> question more generally, at least as far as comp.lang.c goes).

Also agreed, at least partly.  I think it would not be unreasonable to 
require a diagnostic in some cases where the behaviour is clearly 
undefined, but I can understand why the C standards are reluctant to do so.

>
>>> Second, using 'static' in this way resembles how 'restrict' works
>>> with pointer parameters.  The 'static'-ness of the array is not
>>> part of the type of the function, and it doesn't have to be the
>>> same in declarations as it is in the definition.  Normally any
>>> functions defined with this use of 'static' will also have
>>> 'static' in their declarations, but doing that is really just for
>>> documentation, not anything else.
>>
>> I am a big fan of such documentation - and I am very strict about
>> declarations and definitions matching exactly (stricter than the
>> compiler requires).
>
> I agree everything should be in sync.  My preference, when
> possible, is to auto-generate the appropriate declarations based
> on the corresponding definitions.  If you can get other people
> to buy into that, I find it enormously effective in terms of
> both productivity and confidence in the result.

I always insist that any functions (or variables) exported in a module 
are declared with an "extern" in a matching header, that the module 
imports its own header, and that any non-exported functions (or 
variables) are declared "static".  gcc warnings can enforce that, at 
least to the level of making sure that the declarations and definitions 
are compatible.  I'm not so keen on automatically generating the 
declarations, but I guess that works too.

>
>>> Third, what happens with such 'static' parameters when compiling
>>> calls to the function is analogous to compiling calls to
>>> functions whose parameters have 'restrict' qualifiers.  It
>>> doesn't imply any extra checking or constraint validation.  (Of
>>> course implementations are free to do extra checking if they
>>> want, but none is required.)  What using 'static' does is
>>> impose an additional /un/checked requirement that any actual
>>> argument have at least that many elements;  not meeting that
>>> requirement makes the call be undefined behavior.
>>
>> Fair enough.
>>
>> It is nice if the compiler (or possibly other static error
>> checkers) can check it.
>
> Any diagnostic of this sort (ie, which is undecidable in the
> general case) comes with problems - false positives, false
> negatives, or possibly both.  Also, something that may not
> have occured to you, the array bound after the 'static' might
> not be a constant.  C99 has variable length arrays, which
> means that this
>
>      int
>      foo( int n, int v[ static n ] ){
>          ...
>      }
>
> is legal.  Cases like this are much harder to check.

I had noticed that too, and agree that these are even harder to check.

>
> I sympathize with your desire to have diagnostics produced, where
> possible.  But this is a QOI concern, not a language concern, and
> ANSI/ISO made a deliberate choice to not address QOI matters in
> the C standard.  Because of that, it doesn't surprise me, or
> disappoint me, that the possibility of doing such a check for
> 'static' parameters was ignored in defining the C language.

I think the C standards could have been stricter in their definition of 
static parameters, and therefore allow better diagnostics - without 
necessary requiring them.

I suppose compiler developers can make warnings that enforce stronger 
rules on static parameters than the standards - there is nothing to stop 
a compiler warning if there are multiple declarations that don't match 
the definition with regard to the size of the static parameters (as long 
as it accepts legal, but silly and inconsistent code by default).

>
>>> Incidentally, note that the length parameter is also not part of
>>> the parameter type, and hence may be different between a function
>>> declaration and its definition.  Thus we might have
>>>
>>>      int foo( int x[ static 200 ] );
>>>
>>>      ...
>>>
>>>      int
>>>      foo( int x[ static 100 ] ){
>>>          ...
>>>      }
>>>
>>> which the Standard allows.  What I believe is true in such
>>> cases is that both conditions must be met, ie, the larger
>>> value is the one that the compiler may assume.  However
>>> the Standard is not completely clear on the matter, so for
>>> safety the different values should all agree (and probably
>>> expect the value on the function /definition/ to take
>>> precedence, although again the Standard isn't completely
>>> clear on the matter).
>>
>> All in all, it sounds like a nice idea, but a little disappointing
>> in practice.  I would have preferred the standards (and compiler)
>> to be a lot stricter in checking such things.
>
> I explained above why the Standard doesn't address it.  As for
> compilers, of course they could, but I expect there isn't much
> call to do so, especially since there is no guarantee that the
> declarations used match the definitions.
>
>> I can understand
>> that for backward compatibility, and the way arrays are handled
>> and passed in C, that it is hard for the compiler to enforce or
>> assume anything about array parameters that are not declared with
>> this "static".  But I had hoped that it could do more with the
>> added "static".
>
> The problem is undecidable.  Anything that might be done is
> a compromise that some people will be happy with and others
> will not.  Unless the user community cries out for something
> I don't think anything will be done, especially since the
> problem is not just undecidable but difficult to do even
> fairly well.  I believe the perception is that the ROI is
> just not very high.
>
>> As far as I can tell, the explicit undefined behaviour gives the
>> compiler a freer hand for optimisation, and that's about it.
>
> Yes, that is it, exactly it!
>
>> (Compilers /could/ implement a little more static error checking,
>> but extrapolating wildly from my sample of 1 test, they apparently
>> don't do so.  Perhaps it's simply because this use of "static" is
>> not common, so it is not a feature that the gcc folk have
>> implemented.)
>
> And that it is hard to do well.
>
>> As for documentation - and therefore "manual" enforcement, I don't
>> see that the use of "static" adds anything, at least for my own
>> code.  If I declare a function to have a parameter "int x[100]",
>> then it is clear to me that this function wants an array of at
>> least 100 int's.  The "static" is superfluous from the
>> documentation viewpoint.
>
> I think you might want to re-think this position.  By way of
> analogy, there's a difference between saying "I'm not going
> to drive faster than 35 miles per hour" and saying "I'm not
> going to drive faster than 35 miles per hour, and if I do
> I agree to pay you as much money as you ask for."  Without
> the 'static', there may be some cases, eg based on the values
> of other parameters, that are still okay.  With the 'static',
> any transgression is irredeemable.  You may choose not to
> make these kinds of distinctions, but other people might,
> and IMO it is worth keeping that in mind.

It is certainly worth knowing that "static" can be used in this way. 
But I am not convinced that it is useful in code.  Because there is no 
enforced consistency in it, and the optimisation possibilities it gives 
are minimal, all it means is that if a function is declared with a 
static array of size 100 then calling that function with a smaller array 
is undefined behaviour even if the non-existent elements are never accessed.

I think a closer analogy would be that a non-static array parameter is 
like a speed limit sign of 35 miles per hour - you can drive any car you 
want on the road, but if you go about 35 miles an hour you will be 
fined, arrested, or other undefined behaviour.  Putting the "static" in 
the array parameter means that you will be fined or arrested if your car 
is capable of going over 35 miles per hour, even if you stick to the 
speed limit.  Now, that can have its uses - such as cycle tracks or 
pavements - but it's not what you want on a typical road.

(It is difficult to make such analogies accurate.  But the key point for 
/me/ is that it is good to know about this use of "static", even though 
I doubt if it will give any real benefit in my own code.)

>
>> [here was the part that I already addressed]
>>
>>>> Is this a use of "static" that you have seen in real code?  Is
>>>> it used much?
>>>
>>> Now that you know what it's for, especially with your general
>>> concerns for performance, I expect you will finds lots of
>>> occasions where it might be useful.
>>
>> I don't actually pass array parameters around that much, and
>> when I do they are often part of a struct anyway.
>
> This statement surprised me.  Do you mean you hardly ever
> pass pointer values as function parameters?  Or types
> like 'char *'?  Both of these cases have some potential
> benefit using 'static'.

I pass pointers around a good deal less than you might expect in more 
typical C code.  Most of my work is with small embedded systems, and the 
type of code is quite different from what one might find on a PC.  For 
example, I almost never have any sort of dynamic memory in my code.  And 
for some of the cpus I use, any sort of pointer is quite inefficient - I 
would avoid them if possible.

But I don't quite see why static array parameters would be of benefit 
when I have a function using pointers.  For example, if I have the function:

	void displayMessage(int length, const char* msg);

I /could/ change it to:

	void displayMessage(int length, const char[static length]);

And it would work the same.  But I don't see any benefit here.  There is 
no benefit in documentation or clarity of code - the original function 
would be clear already based on its name, its parameter names, the 
context and surrounding comments.  So unless the compiler can give me 
additional help in spotting errors, it is of no advantage.


However, times change - my work involves a greater proportion of bigger 
cpus than it used to, and I am seeing more pointer usage.  It may be 
that I will also see more use of array parameters for which "static" 
could be appropriate.

>
>> And while
>> performance and optimisation opportunities are often a concern
>> (smaller and faster code can mean smaller and cheaper
>> microcontrollers, or lower power or less electrical noise), I
>> see it as unlikely that this "static" qualifier will actually
>> lead to faster code on the types of cpus and with the types of
>> code that I use.  Still, I am always on the lookout for new
>> tools in the toolbox, especially if it can (in theory at least)
>> lead to more precise specification and more static error
>> analysis.
>
> A pointer parameter declared like 'T x[ static 1 ]' is one that
> the compiler may assume is non-null, which may very well help
> code generation even on very low-end CPU's.  (Disclaimer:  I
> am certainly not an expect on optimization, but I see gcc do
> some amazing things based on such "facts", so it seems fair
> to say that the scenario is at least plausible.)
>

I can see that as a possibility.

On the other hand, I can use the gcc attribute "nonnull" on the function 
to tell it that the pointer may not be null.  And then the compiler not 
only will optimise using that information, it will also check it (where 
possible at compile-time) and issue diagnostics.  Additionally, I think 
the "nonnull" attribute expresses the intent a lot more directly and 
clearly than using a static array parameter.

But of course the nonnull attribute is gcc-specific (possibly supported 
by clang).

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

#71432

On Sunday, September 13, 2015 at 8:49:09 AM UTC-5, David Brown wrote:
> It is certainly worth knowing that "static" can be used in this way. 
> But I am not convinced that it is useful in code.  Because there is no 
> enforced consistency in it, and the optimisation possibilities it gives 
> are minimal, all it means is that if a function is declared with a 
> static array of size 100 then calling that function with a smaller array 
> is undefined behaviour even if the non-existent elements are never accessed.

Consider the code:

    int find_nonzero(static int foo[16384])
    {
      for (int i=0; i<16384; i++)
      {
        if (foo[i]) return 1;
      }
      return 0;
    }

Without the static declaration, code for many platforms would be forbidden
from reading any value of "foo" without having checked whether the previous
value was non-zero (some platforms offer an architectural guarantee that
reading any address--valid or not--will have no effect besides yielding some
value, but the platforms where read-ahead is most useful generally trap on
at least some invalid reads).  Adding the "static" declaration would allow
a compiler to rewrite the code as:

    int anything_nonzero(static int foo[16384])
    {
      int a,b,c,d,*end;
     
      end=foo+16384;
      do
      {
        a=*foo++; b=*foo++; c=*foo++; d=*foo++;
        if (a|b|c|d)
          return 1;
      } while(foo < end);
      return 0;
    }

An optimized version of the first loop version for the ARM7-TDMI would be:

LP:
    LDR   R1,[R0],#4
    CMP   R1,#1   ; Carry set if non-zero
    ADDCS R2,#1   ; Arrange to hit zero at end of loop [and set carry then]
    BCC   LP
    ; At this point, R2 will be non-zero if we exited early

Three cycles for the load and branch, and one for each other instruction, so
eight cycles per integer.  I don't think there's any way to improve the
code while preserving the required semantics in cases where the received
pointer is near the end of memory.  The second version could be easily
optimized to:

LP:
    LDRMIA R0,{R4,R5,R6,R7} ; Fetch four integers at once
    IOR    R7,R7,R6
    IOR    R7,R7,R5
    IORS   R7,R7,R4
    BNE    Done
    CMP    R0,R1
    BCC    LP

The LDRMIA would take six cycles, the branch-taken would take 3, and the
other five instructions would take one each, for a total of 14 cycles to
handle four integers, or 3.5 cycles each, a better than 50% improvement,
and that's not even the best code possible.  There are actually two more
places a cycle can be cut out of the latter loop (reducing it to 3 cycles
per integer) but I wouldn't expect a compiler to find them.

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

#71433

supercat@casperkitty.com writes:
[...]
> Consider the code:
>
>     int find_nonzero(static int foo[16384])
>     {
[...]
>     }

The correct syntax is:

    int find_nonzero(int foo[static 16384])

[...]

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

#71437

On Tuesday, September 29, 2015 at 11:18:55 AM UTC-5, Keith Thompson wrote:

> The correct syntax is:
> 
>     int find_nonzero(int foo[static 16384])

Mea culpa.  I think my point stands, though, which is that it gives the
compiler permission to access elements of `foo` in advance of discovering
that their values are needed.  Some would argue that such a thing should
be better notated by adding a reference to "foo[16383]" early in the code,
and others (myself included) might suggest that a new keyword starting with
double-underscores might have been a better choice [so that compilers
which don't understand the notation could be made to ignore it by simply
adding e.g. "#define __stdc_readahead"] but having a means of suggesting
that a compiler should feel free to read data ahead of time, but should
feel no imperative to do so unless it's useful, would seem like a good
concept [IMHO, things that look like executable code should have a purpose
if executed; I dislike the idea of writing things that look like executable
code for the purpose of affecting the compiler's treatment of other code
while hoping that the code I wrote for that purpose doesn't actually end up
in the executable].

[toc] | [prev] | [standalone]

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

csiph-web