m68k arch/cpu directives

m68k arch/cpu directives

[Vincent Rivière]

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...

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...

Any hint will be appreciated.

-- 
Vincent Rivière

Re: m68k arch/cpu directives

[Vincent Rivière]

Hello.

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.

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.

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.

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.
And maybe report a bug to the GCC team, if we consider there was a 
regression.

Any hint in that area will be welcome.

Regards,

--
Vincent Rivière

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...
>
> 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...
>
> Any hint will be appreciated.

Re: m68k arch/cpu directives

[Gunther Nikl]

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