[uClinux-dev] Re: [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation
Hi Geert, On 02/06/11 17:43, Geert Uytterhoeven wrote: On Thu, Jun 2, 2011 at 07:18, Greg Ungerer wrote: On 26/05/11 16:38, Geert Uytterhoeven wrote: I was more thinking along the lines of !CONFIG_M68000&& á!CONFIG_M68010 && á!CONFIG_. 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 Pure positive logic won't work in the (currently stil pathological) case you're building a multi-platform kernel, and have both CONFIG_M68020 and a lesser one that doesn't support cpu32 instructions selected. True. Though we could re-arrange the code blocks to keep the logic positive. So for the memcpy.c case something like: #if defined(CONFIG_COLDFIRE) || defined(CONFIG_M68000) || \ defined(CONFIG_MCPU32) /* the simple code */ #else /* the real 68020+ code */ #endif Now the code doesn't yet have the defines CONFIG_M68000 and CONFIG_MCPU32. But I have a patch ready to send that introduces them :-) Regards Greg ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation
On Thu, Jun 2, 2011 at 07:18, Greg Ungerer wrote:
> On 26/05/11 16:38, Geert Uytterhoeven wrote:
>> I was more thinking along the lines of !CONFIG_M68000&& !CONFIG_M68010
>> && !CONFIG_.
>
> 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
Pure positive logic won't work in the (currently stil pathological) case you're
building a multi-platform kernel, and have both CONFIG_M68020 and a lesser
one that doesn't support cpu32 instructions selected.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation
Hi Geert, On 26/05/11 16:38, Geert Uytterhoeven wrote: On Thu, May 26, 2011 at 08:23, Greg Ungerer wrote: On 24/05/11 18:06, Andreas Schwab wrote: Geert Uytterhoeven á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_. 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 EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Re: [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation
Hi Gavin, On 26/05/11 17:28, Gavin Lambert wrote: Quoth Greg Ungerer: On 24/05/11 18:06, Andreas Schwab wrote: Geert Uytterhoeven 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. Hmm, that has me worried a little. I was thinking about trying to use gcc for a (non-Linux) M68000 device. Does the above mean that this would be problematic? It seems to have been fixed in newer versions of gcc. My current 4.5.1 generates only the defines I would expect based on the supplied machine type options. Regards Greg ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
RE: [uClinux-dev] Re: [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation
Quoth Greg Ungerer: > On 24/05/11 18:06, Andreas Schwab wrote: > > Geert Uytterhoeven 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. Hmm, that has me worried a little. I was thinking about trying to use gcc for a (non-Linux) M68000 device. Does the above mean that this would be problematic? ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation
On Thu, May 26, 2011 at 08:23, Greg Ungerer wrote:
> On 24/05/11 18:06, Andreas Schwab wrote:
>> Geert Uytterhoeven 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_.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation
Hi Andreas, Geert, On 24/05/11 18:06, Andreas Schwab wrote: Geert Uytterhoeven 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. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation
On Mon, May 23, 2011 at 21:54, Andreas Schwab wrote:
> Geert Uytterhoeven writes:
>
>> FWIW, my m68k-linux-gnu-gcc (4.1.2 20061115 (prerelease)) always defines
>> __mc68000__ and __mc68020__, even when specifying -m68000 on the command
>> line.
>
> m68k-linux has always defined __mc68020__ unconditionally, because it
> does not support anything less.
Sorry, I'm just using my good old m68k-linux-gnu toolchain is a devil
for all ;-)
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.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation
On 24/05/11 05:54, Andreas Schwab wrote: Geert Uytterhoeven writes: FWIW, my m68k-linux-gnu-gcc (4.1.2 20061115 (prerelease)) always defines __mc68000__ and __mc68020__, even when specifying -m68000 on the command line. m68k-linux has always defined __mc68020__ unconditionally, because it does not support anything less. I don't beleive that is always the case: $ m68k-linux-gcc -m68000 -dM -E - < /dev/null | grep 68020 $ m68k-linux-gcc -m5200 -dM -E - < /dev/null | grep 68020 $ m68k-linux-gcc -dM -E - < /dev/null | grep 68020 #define __mc68020__ 1 #define __mc68020 1 #define mc68020 1 $ m68k-linux-gcc -mcpu32 -dM -E - < /dev/null | grep 68020 #define __mc68020__ 1 #define __mc68020 1 #define mc68020 1 $ m68k-linux-gcc --version m68k-linux-gcc (GCC) 4.5.1 Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Regards Greg Greg Ungerer -- Principal EngineerEMAIL: g...@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, AustraliaWEB: http://www.SnapGear.com ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
[uClinux-dev] Re: [PATCH v3 5/6] m68k: remove duplicate memcpy() implementation
On Thu, Apr 21, 2011 at 02:24, wrote:
> +#if defined(__mc68020__) || defined(__mc68030__) || \
> + defined(__mc68040__) || defined(__mc68060__) || defined(__mcpu32__)
FWIW, my m68k-linux-gnu-gcc (4.1.2 20061115 (prerelease)) always defines
__mc68000__ and __mc68020__, even when specifying -m68000 on the command
line.
__mc68030__, __mc68040__, __mc68060__, and __mcpu32__ are only defined
if -m68030, -m68040, -m68060, resp. -mcpu32 is specified on the command line.
So the #ifdef always evaluates to true, and it tries to use the scale
factor for 68000,
which is rejected by the assembler.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
