From mint-bounce@lists.fishpool.fi Mon Apr 26 18:02:16 2010 Message-ID: <4BD60CCB.4060608@freesbee.fr> Date: Mon, 26 Apr 2010 23:59:39 +0200 From: =?ISO-8859-1?Q?Vincent_Rivi=E8re?= User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mint@lists.fishpool.fi Subject: Re: [MiNT] "local return" in gnu as References: <20100426220724.3267dc9c.mandin.patrice@orange.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Antivirus: avast! (VPS 100426-0, 26/04/2010), Outbound message X-Antivirus-Status: Clean X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: vincent.riviere@freesbee.fr Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.sparemint.org id o3QM2FFB011614 Miro Kropacek wrote: > But that 'mc68000' definition should be definitely same in all > versions I think... > > To save someone (Vincent ;-) work, I tested various #ifdefs. Results are: > > gcc 2.95 uses 'mc68000' for 68000 target and 'mc68020' for 68020+. > gcc 4.x uses 'mc68000' everytime (!) plus 'mc680x0' for 680x0 targets > (x>=1). Thanks for your contribution to keep my holidays quiet :-) One day I had a look to that GCC defines, and I went to the conclusion it was quite a mess. I chose to keep the standard GCC 4.x behaviour, plus some other defines for compatibility with old compilers. The standard behaviour of GCC 4.x is defined here: http://gcc.gnu.org/viewcvs/trunk/gcc/config/m68k/m68k.h?view=markup Search for TARGET_CPU_CPP_BUILTINS We can see the definition of the mad behaviour you have found: mc68000 is defined everytime, including ColdFire ! Of course, that stuff could be overridden for any target, but it seems insane to have different defines relative to the CPU for different targets. For compatibility with GCC 2.95, I have added the following stuff in the MiNT patch: +/* The following defines are nonstandard + and are kept only for compatibility + with older versions of GCC for MiNT. */ + +#undef CPP_SPEC +#define CPP_SPEC \ + "%{m68000:-D__M68000__} " \ + "%{mc68020:-D__M68020__} " \ + "%{m68020:-D__M68020__} " \ + "%{m68030:-D__M68020__} " \ + "%{m68040:-D__M68020__} " \ + "%{m68060:-D__M68020__} " \ + "%{m68020-40:-D__M68020__} " \ + "%{m68020-60:-D__M68020__} " \ + "%{!m680*:%{!mc680*:-D__M68000__}} " \ + "%{m68881:-D__M68881__} " \ + "%{mshort:-D__MSHORT__}" The first field is the GCC command line option, the second one is the define automatically added. We can see you can test __M68000__ to see if we are compiling for a raw 68000. I think it is also supported by GCC 2.95 for MiNT. However this define does not seem to be standard for others GCC m68k targets (but who cares ?). > - removing 'local' and replacing the label with some unique identifier > (\@) (as gas 2.13 don't know ".altmacro" keyword but uses this mode by > default, it seems better to me to replace this alternate notation > instead of checking for 2.95 gcc in asm source...) I have no knowledge about that, I have not hacked that in the new binutils patch. I don't know these macro features, but your solution seem sensible. Good luck. -- Vincent Rivière