All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Ungerer <gerg@snapgear.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Andreas Schwab <schwab@linux-m68k.org>,
	linux-m68k@vger.kernel.org, uclinux-dev@uclinux.org,
	Greg Ungerer <gerg@uclinux.org>
Subject: Re: [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation
Date: Thu, 2 Jun 2011 15:18:53 +1000	[thread overview]
Message-ID: <4DE71D3D.1080203@snapgear.com> (raw)
In-Reply-To: <BANLkTinAJPBc=Dzy8vZOhcGME55vNc49qg@mail.gmail.com>


Hi Geert,

On 26/05/11 16:38, Geert Uytterhoeven wrote:
> On Thu, May 26, 2011 at 08:23, Greg Ungerer<gerg@snapgear.com>  wrote:
>> On 24/05/11 18:06, Andreas Schwab wrote:
>>> Geert Uytterhoeven<geert@linux-m68k.org>  áwrites:
>>>
>>>> What exactly do you mean by "does not support anything less"? It seems it
>>>> does
>>>> restrict instruction generation to 68000 if you ask for it.
>>>
>>> The point is that Linux/m68k requires 68020+, so compiling for 68000
>>> does not make sense (at least back when the gcc configuration was
>>> created).
>>
>> Yeah, used to be true :-)
>> This seems very much to me to be a "broken compiler" issue.
>>
>> Is it worth putting some form of compiler version limits to protect
>> compilation in the m68000 case? á(Probably no need to limit it for
>> the existing 68020+ case).
>>
>> Are there any other gcc defines that we could use instead?
>> We need to check with your old compiler Geert :-)
>>
>> I really don't want to use CONFIG_MMU here (or in bitops.h either).
>> When I work in the ColdFire MMU code this won't be right.
>
> I was more thinking along the lines of !CONFIG_M68000&&  !CONFIG_M68010
> &&  !CONFIG_<whatever Coldfire that doesn't support it>.

Or in this case (and probably most cases) we could just switch
to using the same positive logic. So what I had as:

#if defined(__mc68020__) || defined(__mc68030__) || \
     defined(__mc68040__) || defined(__mc68060__) || defined(__mcpu32__)

becomes

#if defined(CONFIG_M68020) || defined(CONFIG_M68030) || \
     defined(CONFIG_M68040) || defined(CONFIG_M68060) || \
     defined(CONFIG_MCPU32)

There currently isn't a CONFIG_MCPU32, but I could easily add
that (we only have one CPU in that class currently supported,
the 68360).

The compiler setting won't matter, only what we configured.
Sam will probably like this better, he suggested using the
kernel configs initially, in
http://www.spinics.net/lists/linux-m68k/msg03609.html

I will prepare some patches that do this and see how they look.

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close                             FAX:         +61 7 3217 5323
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com

  reply	other threads:[~2011-06-02  5:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-21  0:24 [PATCH v3 0/6] m68knommu: merge and clean up of arch/m68k/lib files gerg
2011-04-21  0:24 ` [PATCH v3 1/6] m68k: merge mmu and non-mmu versions of muldi3 gerg
2011-04-21  0:24   ` [PATCH v3 2/6] m68k: merge mmu and non-mmu versions of lib/Makefile gerg
2011-04-21  0:24     ` [PATCH v3 3/6] m68k: remove duplicate memmove() implementation gerg
2011-04-21  0:24       ` [PATCH v3 4/6] m68k: remove duplicate memset() implementation gerg
2011-04-21  0:24         ` [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation gerg
2011-04-21  0:24           ` [PATCH v3 6/6] m68k: let Makefile sort out compiling mmu and non-mmu lib/checksum.c gerg
2011-05-23 19:26           ` [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation Geert Uytterhoeven
2011-05-23 19:54             ` Andreas Schwab
2011-05-23 23:55               ` Greg Ungerer
2011-05-24  7:34                 ` Andreas Schwab
2011-05-24  7:51               ` Geert Uytterhoeven
2011-05-24  8:06                 ` Andreas Schwab
2011-05-26  6:23                   ` Greg Ungerer
2011-05-26  6:38                     ` Geert Uytterhoeven
2011-06-02  5:18                       ` Greg Ungerer [this message]
2011-06-02  7:43                         ` Geert Uytterhoeven
2011-06-02 12:34                           ` Greg Ungerer
2011-05-26  7:28                     ` Gavin Lambert
2011-05-26 11:30                       ` [uClinux-dev] " Greg Ungerer

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=4DE71D3D.1080203@snapgear.com \
    --to=gerg@snapgear.com \
    --cc=geert@linux-m68k.org \
    --cc=gerg@uclinux.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=schwab@linux-m68k.org \
    --cc=uclinux-dev@uclinux.org \
    /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.