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