Multilib swamp

[Joel Sherrill <joel@OARcorp.com>]

Till Straumann wrote:
> Peter Dufault wrote:
> 
>>
>> On Mar 1, 2005, at 3:56 PM, Till Straumann wrote:
>>
>>> Peter Dufault wrote:
>>>
>>>> I want to add the DBAT{4,5,6,7}{U,L} registers and asm access 
>>>> routines for the additional BAT registers present on the MPC7455. I 
>>>> plan to define a feature test such as PPC_HAS_8_BATS to 
>>>> conditionalize it on to rtems/score/powerpc.h.
>>>
>>>
>>>
>>>
>>> PLEASE don't - this will get us into the multilib swamp again.
>>> Consider a run-time check for CPU version that generates an error
>>> if the CPU executing the code doesn't support the additional BATs.
>>>
>>> AFAIK, the init-code testing the CPU version would also have to
>>> enable the additional bats, wouldn't it?
>>
>>
>>
>>
>> (uh-oh, back in the multilib swamp)
>>
>> I thought about this some more while researching enabling BATs, and I 
>> have only one complaint about run-time only code.  I said something 
>> earlier about code size, but I don't really care that much about code 
>> size except very rarely, and then I wind up tearing the source apart 
>> anyway to squeeze things in a straitjacket.  The additional size to 
>> handle processor types from embedded to full-blown on PPC is minimal 
>> in an application that pulls in referenced code at link time.  But I 
>> am concerned that leaving obvious failures to run-time (that is, 
>> potentially referencing a non-existent processor capability) is 
>> equivalent to a big complaint that I have with using most interpreted 
>> languages in critical systems - leaving blatant error detection until 
>> run time, especially given the vaguearies of run-time code path 
>> determination and when you might finally find a run-time error.
>>
>> So, I see where you're coming from, but can you help address the above 
>> concern at the same time? 
> 
> 
> Hmm - it's still a little different from syntax checking [interpreted 
> vs. compiled]. You still
> could end up compiling for the wrong variant - an error which you would 
> detect only
> at run-time. OTOH, the run-time checking also allows application code to 
> behave differently
> [without having to propagate #ifdef], e.g.,
> 
> if ( set_dbat(8,xxx) ) {
>   /* use another method, complain or disable feature on this platform */
> }
> 
> vs.
> 
> #ifdef __xxx__
> set_dbat(8,xxx);
> #else
> use_other_method();
> #endif
> 
> I would argue that whereas conditional compilation reduces the 
> 'vaguearies of run-time code
> path determination' it shifts this problem simply to compile-time [many 
> possibly erroneous
> #ifdef combinations are never really tested or even seen by the compiler 
> - hence the fact
> that the compiler/linker doesn't detect an error on a given platform 
> doesn't prove that
> your code is correct either]
> 
> Short answer: I guess I have no good answer...

I have to agree there is no perfect answer to this problem.  We are
making compromises.  We want to treat the RTEMS code under cpukit
as a multlibable library.  That means that nothing can go in there which
needs specific information about a CPU model.

Sometimes this just means moving a code fragment where it is allowed
to know the CPU model.  But other times it means that we choose a
slightly more general implementation to avoid having variants.

I don't know the rule which tells if a PPC model has 4 or 8 BAT
registers.  I would suspect it is tied to the CPU core but don't
know.  It would take some research on Motorola's or FreeScale's site
to figure out.

Dynamically checking the CPU/board for things during initialization is
pretty nice because it trades a small bit of code space for a BSP that
can work unchanged across multiple variants.  The basic motorola_shared
BSP can often run simple programs unchanged on untested board models.

I know TIll and I are being non-committal here but the perfect decision
varies based upon the code in question, when it is executed. and when it 
can vary.  Untested or untestable code is obviously bad.  Creating
multilib variants is even worse.  Given that this is an initialization
issue, I would lean to dynamic checking -- this code ends up under
libbsp anyway.

--joel