[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RFC: Core constructors.
- Date: Mon, 10 Dec 2007 20:38:21 +1100
- From: chrisj at rtems.org (Chris Johns)
- Subject: RFC: Core constructors.
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.
> 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.