There is a subtle difference of concept between architecture and cpu, and I didn't figure how it was supposed to work. Maybe, that's just buggy.
Are you sure there's a difference? It makes sense for gcc but not for gas, as far as I can imagine. Putting different .arch/.cpu yields an error so... it doesn't matter which one you use. Perhaps it's there only for compatibility reasons with gcc? (so both -march and -mcpu would generate code for the given cpu).
Basically, architecture and cpu can be passed on the gas command line. Then then can be overridden in the sources with .arch and .cpu. Unfortunately, specifying one does not automatically set the other one, so in order to be reliable in all cases, both have to be specified.
Can you show us a problematic use case here? It's specifically about the -m68020-60 parameter?
I have asked help about that odd behavior on the binutils mailing list, but with poor success:
http://sourceware.org/ml/binutils/2013-01/msg00199.html
It's been only a day ;) Anyway, an answer for the third question is in gas info: This directive cannot be specified after any instructions have been assembled. If it is given multiple times, or in conjunction with the `-march' option, all uses must be for the same architecture and extension set. (same for .cpu)
My initial plan was to fix those compilation issues for the FreeMiNT 1.18 release, but I don't know what the right fix is. We could add both .arch/.cpu in the assembler files, but that may be a suboptimal solution if the problem is actually caused by a gcc/binutils bug.
As I see it, we only need to change all .arch's into .cpu's and problem is solved.