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
