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

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

Re: English Idiom in Unix: Directory Recursively

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: English Idiom in Unix: Directory Recursively Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-21 09:32 +0100
    Re: English Idiom in Unix: Directory Recursively Lars Enderin <lars.enderin@telia.com> - 2011-05-21 11:52 +0200
      Re: English Idiom in Unix: Directory Recursively Lars Enderin <lars.enderin@telia.com> - 2011-05-21 11:54 +0200
        Re: English Idiom in Unix: Directory Recursively Lars Enderin <lars.enderin@telia.com> - 2011-05-21 11:56 +0200
    Re: English Idiom in Unix: Directory Recursively Gerhard Fiedler <gelists@gmail.com> - 2011-05-21 11:33 -0300
      Re: English Idiom in Unix: Directory Recursively Seebs <usenet-nospam@seebs.net> - 2011-05-21 18:37 +0000
    Re: English Idiom in Unix: Directory Recursively Kenneth Brody <kenbrody@spamcop.net> - 2011-05-23 12:49 -0400

#4488 — Re: English Idiom in Unix: Directory Recursively

> The supposed inefficiency of recursive implementations is based 
> largely on the properties of hardware that is now obsolete. With 
> modern processors there's no great efficiency hit. In some of the 
> smaller microcontrollers, it's true, you do have to worry about stack 
> overflow; but the ARM processors, for example, provide plenty of stack 
> space.
>
> In the microcontroller world, the big performance hits come from the 
> fact that the only available compilers are for C and sometimes C++. 
> (And nobody uses assembly language except for the very little jobs.) 
> The nature of the C language prevents compilers from doing 
> optimisations that are standard in compilers for high-level languages. 
> Most C compilers will, for example, always pass parameters on the 
> stack, despite the generous supply of registers available in newer 
> hardware.
>
However, some C compilers will *also* have one or more "go faster" 
calling conventions that pass parameters in registers, which can be 
employed.  Over in the PC world, such "go faster" calling conventions 
are even the default calling convention if no calling convention is 
explicitly specified, for some C and C++ compilers.

     
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/function-calling-conventions.html#Compiler
     
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/function-calling-conventions.html#Optlink
     
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/function-calling-conventions.html#Watcall

[toc] | [next] | [standalone]

#4489

2011-05-21 10:32, Jonathan de Boyne Pollard skrev:
>> The supposed inefficiency of recursive implementations is based
>> largely on the properties of hardware that is now obsolete. With
>> modern processors there's no great efficiency hit. In some of the
>> smaller microcontrollers, it's true, you do have to worry about stack
>> overflow; but the ARM processors, for example, provide plenty of stack
>> space.
>>
>> In the microcontroller world, the big performance hits come from the
>> fact that the only available compilers are for C and sometimes C++.
>> (And nobody uses assembly language except for the very little jobs.)
>> The nature of the C language prevents compilers from doing
>> optimisations that are standard in compilers for high-level languages.
>> Most C compilers will, for example, always pass parameters on the
>> stack, despite the generous supply of registers available in newer
>> hardware.
>>
> However, some C compilers will *also* have one or more "go faster"
> calling conventions that pass parameters in registers, which can be
> employed.  Over in the PC world, such "go faster" calling conventions
> are even the default calling convention if no calling convention is
> explicitly specified, for some C and C++ compilers.
> 
>    
> http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/function-calling-conventions.html#Compiler
> 
>    
> http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/function-calling-conventions.html#Optlink
> 
>    
> http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/function-calling-conventions.html#Watcall
> 

Please include attributions, in this case for Peter Moylan and rusi!

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

#4490

2011-05-21 11:52, Lars Enderin skrev:
> 
> Please include attributions, in this case for Peter Moylan and rusi!

Just Peter Moylan, sorry!

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

#4491

2011-05-21 11:54, Lars Enderin skrev:
> 2011-05-21 11:52, Lars Enderin skrev:
>>
>> Please include attributions, in this case for Peter Moylan and rusi!
> 
> Just Peter Moylan, sorry!

Ignore the above.

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

#4493

Jonathan de Boyne Pollard wrote:

>> In the microcontroller world, the big performance hits come from the
>> fact that the only available compilers are for C and sometimes C++.
>> (And nobody uses assembly language except for the very little jobs.)
>> The nature of the C language prevents compilers from doing
>> optimisations that are standard in compilers for high-level
>> languages. Most C compilers will, for example, always pass
>> parameters on the stack, despite the generous supply of registers
>> available in newer hardware. 

I'm not sure this is a limitation of the C language. To me it is, if
this is indeed correct, a limitation of the currently available crop of
C compilers. ("Most" is always a difficult affirmation. You'd have to
review "all" in order to be able to say "most". And you'd forget about
relative importance of individual compilers.)

> However, some C compilers will *also* have one or more "go faster"
> calling conventions that pass parameters in registers, which can be
> employed.  

Also, some C compilers do "whole program optimization" and with that can
tailor the calling code to the called code. There doesn't seem to be
anything in the C language spec that prohibits such things.

Gerhard

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

#4499

On 2011-05-21, Gerhard Fiedler <gelists@gmail.com> wrote:
> Jonathan de Boyne Pollard wrote:
>>> In the microcontroller world, the big performance hits come from the
>>> fact that the only available compilers are for C and sometimes C++.
>>> (And nobody uses assembly language except for the very little jobs.)
>>> The nature of the C language prevents compilers from doing
>>> optimisations that are standard in compilers for high-level
>>> languages. Most C compilers will, for example, always pass
>>> parameters on the stack, despite the generous supply of registers
>>> available in newer hardware. 

> I'm not sure this is a limitation of the C language.

It's not.  It's not even true of C.  It may be true of some ABIs, but
I have seen plenty which regularly use registers in their calling conventions.

> Also, some C compilers do "whole program optimization" and with that can
> tailor the calling code to the called code. There doesn't seem to be
> anything in the C language spec that prohibits such things.

There's not.  Modern optimizations are pretty good.

I don't see any evidence to suggest that these are serious performance
hits.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#4568

On 5/21/2011 4:32 AM, Jonathan de Boyne Pollard wrote:
[...]
>> in compilers for high-level languages. Most C compilers will, for example,
>> always pass parameters on the stack, despite the generous supply of
>> registers available in newer hardware.
>>
> However, some C compilers will *also* have one or more "go faster" calling
> conventions that pass parameters in registers, which can be employed. Over
> in the PC world, such "go faster" calling conventions are even the default
> calling convention if no calling convention is explicitly specified, for
> some C and C++ compilers.
[...]

As I recall, the C compiler for the RS/6000 would pass the first N 
parameters via registers.  Except, of course, for varadic functions such as 
printf(), meaning this is a "real life" example of calling such a function 
without a valid prototype in scope being UB.

-- 
Kenneth Brody

[toc] | [prev] | [standalone]

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

csiph-web