Re: m68k arch/cpu directives

[Gunther Nikl <gnikl at users dot sourceforge dot net>]

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