«

> 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./jonath....html#Compiler

http://homepage.ntlworld.com./jonath...s.html#Optlink

http://homepage.ntlworld.com./jonath...s.html#Watcall

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./jonath....html#Compiler
>
>
> http://homepage.ntlworld.com./jonath...s.html#Optlink
>
>
> http://homepage.ntlworld.com./jonath...s.html#Watcall
>

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

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

Just Peter Moylan, sorry!

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.

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

On 2011-05-21, Gerhard Fiedler <> 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-
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.

On Sat, 21 May 2011 11:33:09 -0300, Gerhard Fiedler wrote:

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

No, but the C language spec only addresses monolithic programs. Most
modern software development involves the use of dynamically-linked
libraries, which requires inter-module calls to conform to an ABI.