Re: [ECOS] A basic question regarding [eCos] performance figures

[sandeep <shimple0 at yahoo dot com>]

thanks andrew, it was quite tips-packed reply. i asked
for opinions, as i have come across certain practices
in past, and i am trying to understand
industry/business practices.

>> when one cites various eCos performance figures
>> related to footprint and timings for core
>> functions (as printed via tm_basic tests) --
>>
>> are those generated using certain compiler flags
>> (like -O2, -Os etc.) applied during compilation and

>> some linker flags for relaxation pass etc. during
>> linking - to reduce code size and also have impact 
>> on execution timings.
> They are generally for the default compiler flags.
I didn't get it clearly. by default flags do you mean
the flags provided as default in appropriate CDLs. but
those could vary.

can you please mention these 'default compiler flags'.

wouldn't it be better that certain standard
compiler/linker flags are laid out under eCos
performance figures obtaining guidelines, that gives a
fairer picture when comparing eCos on various
platforms.

other part of my previous mail wasn't pertaining to
eCos, as in case of eCos all the modified code needs
to be given out.

since the question of eCos code distribution comes
here, i have a long pending question related to this.
i was wondering, if some company not interested in
giving sources for HAL for whatever reasons, can it
workaround the things in following way --

they giveout their HAL as .epk file that contains no
C/C++/assembly sources but a library of hal sources
and  needed header files, and some CDL(s) to provide
some configurability. They provide (if needed) a patch
to patch ecos build infrastructure to work with what
they are providing and transparent tricks to integrate
the user choices in the application that is built
using rest of the eCos and this hal library.

sure, it might not give user full fledged
configurability but enough to meet user needs.

do companies also have some non-reverse-engineering
clauses with whatever binaries they are distributing? 

> the application. Optimizing the functions that are
> taking the most time will get you the most gains.
> .....
> The real trick with optimization is not the
> optimization itself, its
> finding where to optimized.
if you find some function or piece of code is getting
called large no. of times, optimising it a bit here
and there, won't it also lead to some improvements in
overall performance (something that i came across
couple of years back, when starting with gprof on
unix)

regards
sandeep


		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss