This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: A basic question regarding [eCos] performance figures


On Thu, Oct 14, 2004 at 05:21:56AM -0700, sandeep wrote:
> 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'.

I mean the default set by cdl. These in theory may vary from platform
to platform, but in practice i think you will find the optimization
flags are the same. I've not actualy checked, so i could be wrong.

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

The distribution method does not matter. The question is the license
on the source code. If its GPL it has to be made available. 

Now porting eCos to a new platform you need to write a HAL. Basically
all HALs are very similar. To write a HAL you copy the most similar
HAL and modify it to your needs. Doing this you have used GPL code, so
your new HAL has to be distributed under GPL.

The same applies to the serial driver, the watchdog, the ethernet
driver etc.

You need to do a clean room implementation of your HAL if you do not
want it to be GPL. I doubt there is enought information in the eCos
Porting guide to writing a HAL without looking at other HALs. So in
practice you will probably first have to spend a long time actually
documenting what a HAL does, so that you can do a clean room
implementation.

I would be supprised if anybody has actually done this. I expect every
port of eCos to a new platform is GPL.

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

This would silly. Why would i bother reverse engineering it, when if i
can show i have legally obtained the device i can simply ask for the
sources to the GPL code on it!

But in most cases, this is missing the point. The eCos HAL is not what
differentiates one product from its competitors. If your competitors
gets the HAL it will not really help them. The value of the product is
in the application, not the eCos port. The application is not covered
by GPL so you are safe, you do not need to distribute it.

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

Generally, a function that is called lots of times, takes up lots of
time. The profiler in eCos tells you want takes the most time, not how
often a function is called. 

        Andrew

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]