This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

m68k machine flags


Benm
the m68k cpu selection and elf flags are somewhat of a mess. I'd like to clean it up in two ways. AFAICT, the elf header flags are not being set by the m68k assembler, so bfd's arch info struct is always defaulting to the plain m68k one. This means we can rationalize the m68k bfd_mach_ enumeration without casing binary incompatibilities (correct me if I'm wrong).


My motivation for this is that we'll be adding more ColdFire variants, and using a simple cpu enumeration is going to be awkward and unordered. I don't mind leaving the 68k specific pieces as unchanged as possible -- fortunately they're pretty linear.

Coldfire has defined a family of architectures (v2, v3, v4, v4e), however they also have a set of ISAs, which don't match up with the above families. IMHO, using the ISAs is the way to go to specify compatibility in object files.

The current capability bits specified in include/opcodes/m68k.h have
isa_a, isa_a+, isa_b, hwdiv, mac, emac, usp, float

Although hwdiv is separated from isa_a, I can't find a CF chip that has just isa without the divide instructions. That seems an unnecessary separation. (gas can assemble for just isa w/o hwdiv, but I don't see the need for that.)

If I'm right, and taking the current ARM implementation as a model to aim for, we should specify a set of ISAs for the bfd_mach enumeration, and then map specific CPUs onto that set in the assembler. The above capabilities are not completely orthogonal, so we can specify some ordering for them. The distinctions needed, I think are

isa_a  + hwdiv			(52xx)
isa_a  + hwdiv + mac		(5206)
isa_a  + hwdiv + emac		(5249)
isa_a+ + hwdiv			(no chip)
isa_a+ + hwdiv + mac		(5208)
isa_a+ + hwdiv + emac		(5329)
isa_a+ + hwdiv + usp		(no chip)
isa_a+ + hwdiv + usp + mac	(no chip)
isa_a+ + hwdiv + usp + emac	(521x)
isa_b  + hwdiv			(no chip)
isa_b  + hwdiv + mac		(5407)
isa_b  + hwdiv + emac		(no chip)
isa_b  + hwdiv + usp + float	(no chip)
isa_b  + hwdiv + usp + float + mac (no chip)
isa_b  + hwdiv + usp + float + emac (547x)

Even though some of these configurations have no chip, I suspect they are still useful categorizations, and it wouldn't surprise me if the gaps got filled at some point.

I'd like to add new gas options for -march=foo and -mcpu=foo, deprecating the existing option mechanism (i.e. leave that as it is, but not advance it for new chips). I think separate switches for specifying mac/emac and for float support would also be good. Thus we'd have
-march=[68kvariants]isaa,isaa+,isab
-musp (with -mnousp?)
-mfloat (with -mnofloat?)
-mmac -mmac=mac,emac (with -mnomac?)
-mcpu=<cpuname>


Clearly some combinations of these would be invalid. I'm not sure having a literal '+' in an option is a good idea, perhaps 'isaaplus'?

thoughts?

nathan

--
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]