Date: Wed, 9 Apr 2003 12:10:31 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Peter Wemm <peter@wemm.org> Cc: David O'Brien <obrien@freebsd.org> Subject: Re: PERFORCE change 28461 for review Message-ID: <20030409191031.GA672@athlon.pn.xcllnt.net> In-Reply-To: <20030409181005.A975B2A7EA@canning.wemm.org> References: <20030409173830.GA549@dhcp01.pn.xcllnt.net> <20030409181005.A975B2A7EA@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 09, 2003 at 11:10:05AM -0700, Peter Wemm wrote: > > > > > > This gets hairy... if the toolchain calls it one thing and we call it > > > another. AMD marketing is trying to squash the "x86-64" name in favaor > > > of "AMD64". Note that "AMD64" is what M$ has always called it... so one > > > has to wonder... > > > > I agree with the concerns, but x86-64 is a particularly ugly name > > and uncomfortable to use in general that I'm inclined to prefer a > > name change in spite of the drawbacks. Think about all the scripts > > and makefiles containing x86_64... *shiver* > > Could we live with a slightly modified toolchain that defines both > __x86_64__ and __amd64__ ? That should be trivial to do. Inherently nonportable code can safely use __amd64__. In fact, for kernel builds you can also add -D__amd64__ on the compile commandline and not have a modified toolchain (not that we should do it that way). > I'd be more than happy to rename everything > so that it was #ifdef __amd64__ and have MACHINE_ARCH=amd64 for > $dir/amd64/* etc. But we can't stop defining __x86_64__ since thats what > linux and the FSF camp appear to use. Lots of third party stuff will have > __x86_64__ ifdefs. Our toolchain makefiles will probably have added complexity to map our name to the name used for targets and platforms. This may add just enough complexity to better drop the whole idea. Just as food for thought: Linux managed to replace i386 with i686. I think there are only very few cases where you really care that i686==i386. In all other cases it's just another platform. The same applies to x86_64 and amd64. > > BTW: To what extend is the actual name important? Is it only > > 'uname -m' that really matters (toolchain bordercases aside)? > > Having $MACHINE_ARCH different to #ifdef __$MACHINE_ARCH__ would be an > ongoing problem I think. True, but aliasing is simple in the preprocessor. You just define as many symbols as you want. I think most of the pain ends up being in configure scripts, makefiles and wrappers. Anyway: It's just preference of someone standing on the sideline here, so feel free to ignore me while moving forward... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030409191031.GA672>