RFC: Core constructors.

[Joel Sherrill]

Chris Johns wrote:
> 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 :-)
>>     
>
>   
I am sensitive to this also. The CVS head is capable of executables
under 32K now on some BSPs but things need to shrink more.  Thomas
were these code or data space issues?

The issue isn't that RTEMS can't be small, it is that we defined
a minimum set of functionality years ago and did all our
minimum footprint analysis around that.  Now it turns out that
users don't always want a filesystem or console IO or ....

We need requirements from users and specific routines that
are showing up in their executable that they don't need or
use directly or indirectly.    It also helps when a user contributes
the code or pays to get the reduction.
> 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. :-)
>
>   
Chris.. do the per-manager initialization routines need to be
changed to not take parameters for configuration information?
>> 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
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>