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

Peter Dufault dufault at
Wed Mar 2 00:48:30 UTC 2005

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 Dufault
HD Associates, Inc.

More information about the users mailing list