All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@codesourcery.com>
To: "Hill, Steven" <sjhill@mips.com>
Cc: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
	"ralf@linux-mips.org" <ralf@linux-mips.org>
Subject: RE: [PATCH 01/10] MIPS: Add core files for MIPS SEAD-3 development platform.
Date: Fri, 11 May 2012 08:37:22 +0100	[thread overview]
Message-ID: <alpine.LFD.2.00.1205082304120.3701@eddie.linux-mips.org> (raw)
In-Reply-To: <31E06A9FC96CEC488B43B19E2957C1B80114692157@exchdb03.mips.com>

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

  reply	other threads:[~2012-05-11  7:37 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-07 16:48 [PATCH 00/10] Add support MIPS SEAD-3 Development Platform Steven J. Hill
2012-04-07 16:48 ` [PATCH 01/10] MIPS: Add core files for MIPS SEAD-3 development platform Steven J. Hill
2012-04-10  1:03   ` Shinya Kuribayashi
2012-05-07 20:16     ` Hill, Steven
2012-05-08  4:01       ` Shinya Kuribayashi
2012-05-08 11:16       ` Maciej W. Rozycki
2012-05-08 20:38         ` Hill, Steven
2012-05-11  7:37           ` Maciej W. Rozycki [this message]
2012-04-07 16:48 ` [PATCH 02/10] MIPS: Changes to configuration files for SEAD-3 platform Steven J. Hill
2012-04-10  1:19   ` Shinya Kuribayashi
2012-04-07 16:48 ` [PATCH 03/10] MIPS: Add support for the M14K core Steven J. Hill
2012-04-07 16:48 ` [PATCH 04/10] MIPS: Add micro-assembler support for 'ins' and 'ext' instructions Steven J. Hill
2012-05-01  0:26   ` Maciej W. Rozycki
2012-05-01  0:51     ` David Daney
2012-05-07  5:18       ` Maciej W. Rozycki
2012-05-07 13:33         ` Hill, Steven
2012-05-01  0:49   ` David Daney
2012-04-07 16:48 ` [PATCH 05/10] MIPS: GIC interrupt changes for M14K and SEAD-3 support Steven J. Hill
2012-04-07 16:48 ` [PATCH 06/10] MIPS: Code formatting fixes Steven J. Hill
2012-04-07 16:48 ` [PATCH 07/10] MIPS: Add support for early serial debug and LCD device on SEAD-3 Steven J. Hill
2012-04-07 16:48 ` [PATCH 08/10] MIPS: MIPS32R2 optimisations for pipeline stalls and code size Steven J. Hill
2012-04-07 16:48 ` [PATCH 09/10] cobalt_lcdfb: LCD panel framebuffer support for SEAD-3 platform Steven J. Hill
2012-04-07 16:48 ` [PATCH 10/10] usb: host: mips: sead3: USB Host controller " Steven J. Hill

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.00.1205082304120.3701@eddie.linux-mips.org \
    --to=macro@codesourcery.com \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=shinya.kuribayashi.px@renesas.com \
    --cc=sjhill@mips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.