Re: m68k arch/cpu directives

[Vincent Rivière <vincent dot riviere at freesbee dot fr>]

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.