> The depth of our binary distribution problem depends on how optimized we
> want to be. As a first cut, we need binaries for:
> 
> 	68000
> 	sparc
> 	mips
> 	alpha
> 	i386
> 	ARM
> 	ns32532
> 	(and some that I've forgotten)

Nit: it's generally most useful to talk about ${MACHINE_ARCH} values,
rather than somewhat-arbitrary names for the architectures.

tha means:

	alpha
	arm32
	i386
	m68k
	mips
	ns32k
	powerpc
	sparc
	vax

(or at least, the subset of those that have real binary distributions
-- probably everything but powerpc, right?)


> but life gets more interesting when one considers more processor specific
> code generation, e.g. 68020? 68030? 68040? 68060? v7 sparc? v8 sparc? 386?
> 486? Pentium? Pentium Pro? Pentium II?

opcode use selection for code generation is easy.  packages should run
on all machines in the ${MACHINE_ARCH}, with the best possible
instruction set performance.

That means opcode selection should be:

	alpha: 21064/ev4
	arm32: ??? (probably v3 of the ARM ISA, i'd guess)
	i386: i386
	m68k: 68020 (excluding instructions later moved to emulation)
	mips: r2000/r3000
	ns32k: ns32532 (there's only one cpu supported, right?)
	powerpc: ???
	sparc: ???
	vax: ???

Instruction scheduling optimization is another matter.  It doesn't
really matter except as a performance and/or size issue.  For that,
the 'common' machines of a given type should be selected, to provide
best performance for a large (preferably the largest) number of users.

Instruction scheduling selection should probably be:

	alpha: 21064A/ev45 (though maybe 21164/ev5 or 21164A/ev56 in
	    the near future)
	arm32: ??? (I'd love to say sa-110... 8-)
	i386: Pentium.
	m68k: probably either '030 or '040.
	mips: ??? (probably r3k or r4k)
	ns32k: ns32532
	powerpc: ???
	sparc: ???
	vax: ???

Instruction scheduling selection is purely a matter of optimization,
however, and not one of compatibility, so consistency isn't quite so
important.


> Sounds like we need a new post: port-package-master (someone for each port
> to build the packages)

Actually, no, not really.  There should be an arch-package-master, who
coordinates with port masters who have a ${MACHINE_ARCH} port.

That person should coordinate with them to not only build and test
ports on all of the relevant architectures, but also to pick the
'right' settings for the flags above for that ${MACHINE_ARCH}.  That
person probably would want testing helpers for each port, but that's
really up to them.


> It gives us an interesting M x N problem. 9GB disks are getting cheaper,
> and there is ccd...

packages * 9 architectures isn't nearly as bad as packages * 17 (or
whatever) ports.




chris