Multilib swamp

[Till Straumann]

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

Cheers
T.

>
> Peter
>
> Peter Dufault
> HD Associates, Inc.
>