Adding new PowerPC platforms to the build

[Marcel Moolenaar]

On Dec 18, 2006, at 5:02 PM, Peter Grehan wrote:

>  See below, I wouldn't want to have a compile-time option for this  
> unless it's absolutely necessary. Put all the CPU-model-specific  
> code in it's own source file, glue them together with linker sets,  
> and pick one at boot-time. If you only want one, then create a  
> custom config that only includes the one of interest. GENERIC can  
> have all of them, within reason.

There's at least 1 gotcha: I think the ABI for embedded space is
different from server space (Book III-E vs Book III-S). Think
floating-point. MI code that is intended to run on a Book III-S
ISA processor should use hardware FP. MI code that is intended
to run on a Book III-E ISA processor cannot.

This seems to indicate that we have more than 1 distinct PowerPC
worlds and that it would not be beneficial to try to combine these
into a single release or build. So, if we can use (say) MACHINE to
indicate the ABI variant (either III-S or III-E, but maybe even VLE)
then we at least separate these worlds and use dynamic linking,
loading, KOBJ-ification et al for runtime selection of features and
code blobs.

In other words: what is the absolute minimum separation we need
to introduce that yields reasonable generic behavior per class
(if at all) and how do we implement that separation in the
source tree. As you say, custom kernels and run-time tuning should
allow us to handle variations within a single class.

For example, the following seems quite user-friendly and intuitive:
	make release TARGET_ARCH=powerpc TARGET=server
or
	make release TARGET_ARCH=powerpc TARGET=embedded

and it does solve the biggest problem we're facing. Would this be
so bad?

Also, I don't want to assume that whatever we do should be done in
the same way as pc98 and sun4u has been done. I think they have set
a bad example. I pretty much assume that TARGET=foo would imply a
directory foo under the TARGET_ARCH directory. In any case, I don't
want to tie myself down to what's there. I want to explore what we
like to be able to do and then fix FreeBSD to allow us to do it.

-- 
Marcel Moolenaar
xcllnt at mac.com