This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: m68k arch/cpu directives
- From: Gunther Nikl <gnikl at users dot sourceforge dot net>
- To: binutils at sourceware dot org
- Cc: Vincent Rivière <vincent dot riviere at freesbee dot fr>
- Date: Tue, 18 Jun 2013 20:47:11 +0200
- Subject: Re: m68k arch/cpu directives
- References: <50F410C9 dot 7060200 at freesbee dot fr> <518AC831 dot 7010402 at freesbee dot fr>
Hello Vincent,
> I noticed a change when switching from m68k GCC 4.6.x to 4.7.1.
>
> - In GCC 4.6, when using -m68000 on the gcc command line, it is kept as
> -m68000 on the as command line.
>
> - In GCC 4.7, when using -m68000 on the gcc command line, it is
> translated to -mcpu=68000 on the as command line.
Yes, GCC 4.7 was changed to convert "legacy" options into their new
canonical form. The rationale being that binutils support for -mcpu=
as well as for -march= are present for a long time and GCC would
require rather new binutils.
> There is a subtle difference. On the as command line, it seems that -m68000
> sets both the architecture and cpu, while -mcpu=68000 sets only the CPU,
> keeping the default architecture. This can cause different behavior when
> .cpu and/or .arch are used at the top of .s files.
Interesting observation, thanks for spotting this! For my port I decided
to not follow the new GCC default. My GCC port keeps passing the legacy
options to gas/ld since my binutils do not support -mcpu=/-march=.
> I wonder if that is a GCC bug or feature.
> In order to answer that question, first I need to deeply understand the
> semantics of .cpu and .arch, and the relationship to the command line
> options.
I can't provide any helpful explanation since I always avoided these
options and still use the original options. My GCC port un-does the GCC
ASM_SPEC change and converts -mcpu=/-march= back to -m<type> like this:
-- cut --
#undef ASM_CPU_SPEC
#define ASM_CPU_SPEC \
"%{mcpu=68000|mcpu=68010:-m68010} " \
"%{mcpu=68020|m68020-*:-m68020} " \
"%{mcpu=68030:-m68030} " \
"%{mcpu=68040:-m68040} " \
"%{mcpu=68060:-m68060} " \
"%{!mcpu=*:%{!m68020-*:%{march=*:-m%*;:-m68010}}}"
-- cut --
Note that handling -march= matches GCC behaviour: Its only used if
no -mcpu= option is present.
I have to admit that I only care for the original architecture.
Coldfire is not relevant to me.
> Ultimately, I want to determine what to put a the top of my .s source
> files to do the right thing, regardless of the cpu/arch options passed
> on the command line.
If you need a certain behavior you probably should provide appropriate
directives in your (assembler) files.
> And maybe report a bug to the GCC team, if we consider there was a
> regression.
IMHO, this is a regression since the assembler behavior is now
different.
> On 14/01/2013 15:06, Vincent Rivière wrote:
>> Hello.
>>
>> I'm a bit puzzled about the various m68k arch/cpu directives in gas.
>>
>> 1) First, I don't really understand the difference between architecture
>> and cpu. It seems that architecture is a general family, while a cpu is
>> a precise model.
>>
>> 2) At the top of an assembly file, it seems that both .arch and .cpu are
>> required to switch to a different CPU than the command line one. Is this
>> really what is expected? I would have imagined that .cpu was enough, and
>> that the architecture would have been automatically deduced...
Yes thats what I would expect as well and thats how amiga assembler
work. However, no amiga assembler I know has an .arch directive.
>> 3) Is it allowed to switch to different cpu instruction set at the
>> middle of an assembly file? This is useful for example to autodetect
>> special CPU features. It seems that doing so is only supported by the
>> .chip directive, which is not documented, and present only for ancient
>> MRI compatibility...
I assumed that these directives have been introduced to do exactly that:
switch instruction sets.
Regards,
Gunther