This is the mail archive of the
mailing list for the binutils project.
Re: m68k arch/cpu directives
- From: Vincent Rivière <vincent dot riviere at freesbee dot fr>
- To: binutils at sourceware dot org
- Date: Wed, 08 May 2013 23:48:33 +0200
- Subject: Re: m68k arch/cpu directives
- References: <50F410C9 dot 7060200 at freesbee dot fr>
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
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
Any hint in that area will be welcome.
On 14/01/2013 15:06, Vincent Rivière wrote:
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
Any hint will be appreciated.