I think so.
If you do "m68k-atari-mint-as --target-help", you will see different lists for "Architecture variants" and "Processor variants". It seems that architectures are more general concepts.
I see. But since we use only the "main" CPUs (defined by .arch) it doesn't matter.
But for example, if I pass -m68020-60 to gcc, it translates to -m68040 for gas. This is totally bogus (should be -m68020). BTW, I see that GCC 4.6 does the same !!
This is definitely wrong. Either -m68020-60 is separately defined for gas and gcc (where it means "generate only 020 code executable on 020/030/040/060) or it's a bug.
gcc-4.7 -m68000 translates to gas -mcpu=68000. This is a problem, because it seems that -m68000 sets both arch/cpu while -mcpu=68000 sets only the cpu. Then afterwards, if some source uses the .cpu or .arch directives, this can result in invalid combinations. However, changing both .cpu/.arch seemed to do the right thing in every case.
Actually, I think it's a feature. I guess the main idea is that you, as a system programmer, can decide, if your code is generic for the given architecture (.arch 68040 for example) or you want to avoid any let's say MMU code and be warned about it by the assembler (.cpu 68ec040). You can perfectly enter .arch 68040 + .cpu 68ec040 as well as only .cpu 68040. In our case it's simple, we've got only "subclasses" which limits the original features, so it's safe to use .cpu everytime.
On the other hand, I don't understand, why 'm68k' is .cpu and not .arch... strange.
--