Subject: Re: MACHINE_ARCH on mips
To: Jason Thorpe <>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-toolchain
Date: 07/26/1998 12:49:23
Jason Thorpe <> writes:

On Sat, 25 Jul 1998 10:33:39 -0700 (PDT) 
 Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:

 > The person who designed that ``promise'' didnt' think about bi-endian
 > machines at the time.  It was discussed again in April.  The decision
 > was not to split ${MACHINE_ARCH}.  CGD and Jason Thorpe concurred.
 > I see a couple of messages from you in the thread, even.

>So maybe I changed my mind.

Well, I _did_ ask to clarify that back in April, in the discussion of
CPP pre-defining __${MACHINE_ARCH}_ and __MIPSEL __MIPSEB I got mildly
flambe'd for checking.  But both you and CGD seemed to agree.

I _still_ don't think it's Not The Right Thing To Do.  If it is, we
need another alternative to ${MACHINE_ARCH} which is "mips" for all

	mipsel		-- mips LE, 32-bit
	mipseb		-- mips BE

	mipseln32	-- mips LE, 32-bit int/pointer,
			   64-bit FPU, 64-bit for 'long long' insns 
	mipsebn32	--  mips BE, 32-bit int/pointer,
			   64-bit FPU, 64-bit for 'long long' insns 

	mipsel64	-- mips LE, LP64
	mipseb64	--  mips BE, LP64

Todd's idea is explicilty that we shoudl split all those, as separate

That means duplicating all the tests for ${MACHINE_ARCH} == mips 
	* all through the Makefile tests for
	  ``should we build this on mips (``any flavour)''
	* all builds that that descend into  an arch/mips dir
	* all through the C source code tests for #ifdef __mips__
	* the pkgsrc tests for ONLY_FOR_ARCHES

which is bad engineering.