RFC: Core constructors.

[Chris Johns]

Thomas Doerfler wrote:
> 
> This sounds perfect.
> 

Ok done. I will change the name. :-)

> Very bad idea: Do you really have to order the list? I guess it is only
> used ONCE (to call the constructor functions). If we have, say 50
> constructors in the system and you perform a repeated search algorithm
> through that list ("who wants to be initialized next?"), the runtime
> impact might be acceptable.

It is only the constructors in a specific class so this improves things. 
Anything over 32 constructors in a class is a big deal.

> 
> Alternatively, the stack or a piece of the workspace/heap might be
> another solution.

I would like to avoid any dynamic memory. That is just moving the problem 
rather than solving it.

> I don't like the idea of using RAM for things that are not required
> during runtime. There are some nice little Coldfire chips with built-in
> RAM, and we alredy have lost two potential RTEMS designs due to the
> current memory requirements, so I am a bit picky here :-)

Yeah so am I and that is why this code is not already in RTEMS.

Sounds like you would like me to code both solutions (one already exists) and 
time them. Good idea. :-)

> Sorry, no offence meant :-)

None observed or taken.

> I meant that one goal, to pull in only those modules that are really
> needed for a system/application will not be met, when let's say the BSP
> references more modules than intended. We all know that a printf in a
> BSP will pull in LOT of stuff, and possibly this is inadverted.

Yes knowing what and why can be involved and time consuming. Any help is a win.

> Would it really? 

What I mean is some languages provide this sort of support as part of the 
language. With C we need to invent the rules and that can be complex.

> My idea is that some linker/objdump/lib tricks might
> lead to the way:
> 1.) make the linker link together all objects of a module (e.g. the
> semaphore manager)

A '-r' type link ?

> 2.) link this "module object" against all knowingly referenced external
> modules, without pulling these objects in (there is a ld option to just
> pull in the references)
> 
> 3.) Any undefined references left over indicate an unexpected dependency.

Interesting.

> I have no idea whether this would directly work, but I think this would
> allow us to detect unwanted references after code modifications rather
> early, especially (but not only) in the BSP area.
> 
> But once again: this is beyond the scope of your improvements.
> 

Yes it is but still interesting.

Regards
Chris