PERFORCE change 28461 for review

[Peter Wemm]

Marcel Moolenaar wrote:
> On Wed, Apr 09, 2003 at 09:04:01AM -0700, David O'Brien wrote:
> > On Tue, Apr 08, 2003 at 10:23:56AM -0400, John Baldwin wrote:
> > > 
> > > On 07-Apr-2003 Peter Wemm wrote:
> > > > http://perforce.freebsd.org/chv.cgi?CH=28461
> > > > 
> > > > Change 28461 by peter at peter_daintree on 2003/04/07 16:35:32
> > > > 
> > > >       use -mcmodel=medium for hammer.  Otherwise it generates
> > > >       32 bit instructions for things like invltlb().  kernel model
> > > >       comes later.
> > > 
> > > Side topic: are we going to call it amd64 some day instead of x86-64?
> > 
> > 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__ ?  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.

> 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.

Cheers,
-Peter
--
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5