On 10 Jul 2000, Chris G. Demetriou wrote:

> tv@pobox.com (Todd Vierling) writes:
> > : gcc for sparc has a MULTI_MODE option where a single cc front end driver
> > : can generate both 32-bit and 64-bit binaries based on a single command
> > : line option.
> > 
> > MIPS has something very similar; -EB and -EL for big-endian and
> > little-endian, respectively.
> 
> actually, mips has it much worse.
> 
> the current set of multilibs i build in my gcc are:
> 
> 	EL/EB
> 
> 		endianness

[Can you actually support running a process in other-endian mode without
breaking things on (say) mips4?  Especially re: file I/O?]

> 	mips1/mips2/mips3/mips4
> 
> 		ISA level -- this is gonna get about 50% worse, too.
> 
> 	mlong32/mlong64
> 
> 		long/pointer size model.  (ILP32 vs LP64).
> 
> and i could be, but don't, built variants for:
> 
> 	msoft-float/mhard-float/msingle-float
> 
> 
> Note that not all of these combinations are actually sensible
> (e.g. mips1 & mips2 and mlong64), but the majority are...

How are you handling this now?  Is is viable long-term having
/emul/mipsel32, /emul/mipseb32, /emul/mipsel64, /emul/mipseb64, etc?

Eduardo Horvath