From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Ungerer Subject: Re: [PATCH 32/35] m68k: add ColdFire FPU support for the V4e ColdFire CPU's Date: Wed, 28 Dec 2011 22:32:03 +1000 Message-ID: <4EFB0C43.20605@snapgear.com> References: <1324610148-20666-1-git-send-email-gerg@snapgear.com> <1324610148-20666-33-git-send-email-gerg@snapgear.com> <4EFAAEF3.6010709@snapgear.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from sncsmrelay2.nai.com ([67.97.80.206]:54203 "EHLO sncsmrelay2.nai.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751213Ab1L1McU (ORCPT ); Wed, 28 Dec 2011 07:32:20 -0500 In-Reply-To: Sender: linux-m68k-owner@vger.kernel.org List-Id: linux-m68k@vger.kernel.org To: Geert Uytterhoeven Cc: linux-m68k@vger.kernel.org, uclinux-dev@uclinux.org, Greg Ungerer Hi Geert, On 12/28/2011 08:06 PM, Geert Uytterhoeven wrote: > On Wed, Dec 28, 2011 at 06:53, Greg Ungerer wrote: >> If we are compiling specifically for a 68040 machine, where we put >> a -m68040 switch on the command line, isn't all these ".chip 68k" >> lines going to undo the CPU choice - and result in us now compiling >> large parts of the code for the default 68020 instead of the chosen >> 68040? > > No, it's a directive for the assembler, not for the compiler. Good point :-) > It may cause issues for mnemonics (generated by the compiler) that > exist for both classic and coldfire, but have different opcodes. > Do these actually exist? None that I could find. But the compiler might generate code that is coldfire only. And with that ".chip m68k" directive there it will error out. (Actually more likely - and this I have seen - is that some of the asm code that is coldfire specific trips it up). There is a handful of new and different instructions in newer ColdFires. But even still, compiling with -m68040 causes gcc to generate different code than compiling without it (so effectively with m68020). In cases I looked at the instructions used where still fine to run on either, so nothing specific to the 68040 was generated. But if anything ever was then again the ".chip 68k" would cause an error out. I guess there isn't much extra in the 68040... move16, anything else? I guess gcc will never generate that in practice, so it is not a problem. Regards Greg ------------------------------------------------------------------------ Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close, FAX: +61 7 3891 3630 Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com