Date: Wed, 03 Feb 2010 16:07:15 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: nwhitehorn@freebsd.org, arch@freebsd.org Subject: Re: svn commit: r203446 - in user/imp/tbemd: . bin/pax cddl/lib/libdtrace cddl/lib/libzpool contrib/smbfs etc games/morse gnu/lib/csu gnu/lib/libgcc gnu/lib/libgomp gnu/lib/libstdc++ gnu/usr.bin gnu/us... Message-ID: <20100203.160715.750582998416482087.imp@bsdimp.com> In-Reply-To: <4B69FA08.2070308@freebsd.org> References: <201002032129.o13LT7kZ013039@svn.freebsd.org> <4B69FA08.2070308@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[[ Moved to arch@ ]]
In message: <4B69FA08.2070308@freebsd.org>
Nathan Whitehorn <nwhitehorn@FreeBSD.org> writes:
: Warner Losh wrote:
: > Author: imp
: > Date: Wed Feb 3 21:29:06 2010
: > New Revision: 203446
: > URL: http://svn.freebsd.org/changeset/base/203446
: >
: > Log:
: > Introduce MACHINE_CPUARCH.
: > MACHINE is the specific kernel architecture for this machine.
: > MACHINE_ARCH is the specific CPU type (abi, word size, etc).
: > MACHINE_CPUARCH is the family of CPUs that's supported.
: > Most of the tree conflates MACHINE_ARCH and MACHINE_CPUARCH since
: > historically they have been identical. However, there's now a reason
: > to to split the two concepts. NetBSD calls this MACHINE_CPU, but
: > that's already used for something else in FreeBSD, so MACHINE_CPUARCH
: > was selected instead.
: > However, the sources in the tree have had a KLUDGE in the tree called
: > TARGET_BIG_ENDIAN to select which endian to compile the code for.
: > However, this is a cumbersome and awkward solution. MACHINE_ARCH
: > really does need to be different for different endian because users
: > use it for things like their path. Yet, the source tree also used
: > MACHINE_ARCH to figure out the MD code to use. This source often
: > supports multiple MACHINE_ARCHs. 'mips' supports 32 (and soon 64) bit
: > word sizes as well as big and little endian. 'arm' support both
: > endians. powerpc will soon support both 32-bit and 64-bit.
: > These patches start to unwind this confusion. It implements
: > MACHINE_ARCH of mipsel, mipseb for the two endians of MIPS, as well as
: > arm and armeb for ARM. The names for ARM are historical accidents
: > (ARM was primarily little endian until relatively recently). These
: > names follow the NetBSD convetions.
: > With these changes, "make buildworld TARGET=mips TARGET_ARCH=mipsel"
: > finishes. armeb and mipseb should work, but haven't been tested yet.
: > Committed as one big chunk so that people can comment on the patches
: > as a whole and suggest improvements.
: >
: >
: Thanks for this!
:
: How does this work for ABIs? For big vs. little endian, most if not
: all of the userland support code is invariant. But in the 64/32 bit
: case, 32 and 64-bit PowerPC have wildly differing ABIs, to the point
: that there is extremely little overlap in the support code for things
: like libc and RTLD, and it doesn't make much sense to point them at
: the same directories. Should MACHINE_CPUARCH be different here, or is
: it worth introducing something like MACHINE_ABI as well? I suppose
: there are also individual hacks in Makefiles...
First let me address the powerpc 32-bit vs 64-bit issue. If the
support files really are radically different, then it makes sense in
this case to treat them as two separate MACHINE_CPUARCH instances. We
do this today with x86 and x86_64 (only we call them i386 and amd64).
I anticipate that MIPS will be able to have the same files because
mips64 and mips32 are very similar. The binaries will necessarily be
different, but the sources will be the same with just a few
conditionals and/or clever macros sprinkled through.
This leads us to the orthogonal question of ABI. I like the idea of a
MACHINE_ABI that is the default ABI to compile to. The default ABI is
the one that the programs in the base are built against and that you
get without special magic from the tools. Many ABIs can, on some
systems, live together in peace and harmony. The multilib
functionality allows for the development side of things to flourish,
and there are conventions on where to put o32 vs n32 vs n64 shared
libraries so the system can execute them at any time. I think
multilib could even support multiple endian/word sizes as well, but to
be honest, I've only just skimmed the surface of it.
MACHINE_ABI will be used either to select different directories; used
to instruction the compilers what code to generate (and what defines
to use; etc. In the MIPS case, different ABI support is trivial in
'C' and doable in assembler (we need more pieces of the puzzle than we
have in place for MIPS, but work is progressing there).
It would also mean that for the looming ARM problem we have a
solution. The looming ARM problem is that newer versions of the ARM
ISA are more efficient with newer ABIs than the one we currently use.
In an ideal world, we'd be able to build the tree for either (or both)
and deploy whichever one makes sense for the underlying ARM hardware.
The big trick here is to do this without exploding the testing matrix
that committers will need to run through for their commits.
Does this make sense?
Warner
P.S. This discussion started based on the svn tree I created to
eliminate TARGET_BIG_ENDIAN from the tree, since the limitations of
that were long known, and recently as the number of users has
ballooned, has become painfully obvious...
svn://svn.freebsd.org/base/user/imp/tbemd
(tbemd - TARGET_BIG_ENDIAN Must Die)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100203.160715.750582998416482087.imp>