Multilib swamp (was: Re: PowerPC architecture: Which processors have 8 BAT registers?)

[Peter Dufault]

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?

Peter

Peter Dufault
HD Associates, Inc.