[Top] [All Lists]

RE: [PATCH 01/10] MIPS: Add core files for MIPS SEAD-3 development platf

To: "Hill, Steven" <>
Subject: RE: [PATCH 01/10] MIPS: Add core files for MIPS SEAD-3 development platform.
From: "Maciej W. Rozycki" <>
Date: Fri, 11 May 2012 08:37:22 +0100
Cc: Shinya Kuribayashi <>, "" <>, "" <>
In-reply-to: <>
References: <> <>,<> <>,<> <>
User-agent: Alpine 1.10 (DEB 962 2008-03-14)
On Tue, 8 May 2012, Hill, Steven wrote:

> I thought the "YC" constraint was only present in CodeSourcery 
> toolchains, correct? If so, then that levies the requirement for a 
> vendor-specific toolchain to build a microMIPS kernel. I do not consider 
> that palpable. If it is not CodeSourcery-specific, then I will certainly 
> try it out.

 The GNU GPL applies, these sources are publicly available, so it's not 
like anyone can't use them, integrate into their compiler, etc.  Binutils 
microMIPS support has already been integrated upstream.

 Also is there any other compiler that makes microMIPS code?  If so, then 
I suggest that you convince its maintainers to make a compatible 
constraint available.  We'll need it sooner or later (you can force the 
address into a register of course -- it was already considered a few years 
ago before "R" was fixed in GCC to work reliably -- but I don't expect you 
want such a pessimisation) and anyone implementing microMIPS support in 
their compiler and willing to support building Linux will have to provide 
the necessary constraint just as everyone already has to provide the "R" 
constraint for standard MIPS code.

 Note that as it is, you need to do something about all the code that uses 
"R" with microMIPS instructions that have their immediate offset limited 
to 12 bits anyway -- apart from <asm/cmpxchg.h> considered here this 
includes stuff in <asm/futex.h> and <asm/r4kcache.h>.  I maintain that 
"YC" is your best bet especially given the little effort required to 
handle it, and should any other compiler choose to use a different 
constraint for this purpose, then it can be conditionalised on that 
compiler's ID.

 If you're concerned that "YC" can be used for something else in upstream 
GCC, then we can coordinate this with GCC maintainers -- it's not like 
we're running of of letters here.


<Prev in Thread] Current Thread [Next in Thread>