This is the mail archive of the
mailing list for the CGEN project.
Re: cgen/gas: some support for funny-endian instruction sets
- To: dje at transmeta dot com (Doug Evans)
- Subject: Re: cgen/gas: some support for funny-endian instruction sets
- From: fche at redhat dot com (Frank Ch. Eigler)
- Date: 09 Jul 2001 13:56:45 -0400
- Cc: cgen at sources dot redhat dot com, binutils at sources dot redhat dot com
- References: <20010709123942.Q3715@redhat.com><email@example.com>
: > The gcc meaning might be relevant, if only the word-bitsize parameter
: > was actually used for something in cgen in a similar way than it might
: > be in gcc. Yes, a differently named parameter would be nice, but so
: > would elimination of unused parameters.
: There's a tug-of-war between not specifying things that aren't used
: and providing basic support and/or guidance to future uses of cgen.
That's true, though I wish guidance was less cast in code and more in
documentation or comments. (I also wish I would take this
consideration into account with my own code more consistently :-)
: Just because some attribute of an architecture isn't used by current
: applications of cgen is _not_ a priori reason enough to not specify it.
: In this case I think the presence of word-bitsize is useful.
I quite disagree: to *specify*? If parameters are not used (and there
are a bunch), IMO it is harmful to specify them. They are untestable
decorations. They lead to blind copying from port to port, there
being WIP documentation, no useful definition, no apparent harm
... until cgen starts supporting it. Then, instead of a
cgen-generation-time error ("missing parameter"), one gets a silently
: Some more thoughts ...
: In the beginning I played with whether or not to explicitly specify
: instruction formats. Once you know an instruction's format, you
: know how to chunk up its elements.
Well, that's only true if it's circular: if the insn format
representation accounts for chunking, then yes, it does. It doesn't
have to. Several insn format lists I have seen in processor
documentation don't cover this, treating endianness/chunking as a
separate matter elsewhere (since it's an aspect of the processor's
physical data bus).
: I think the jury is still out but cgen has gotten by without
: explicitly specifying them this far. [...]
Well, more challenging targets have only started arriving in the
last year or so. :-)
: [...] Do you think a more appropriate solution would be found by
: [providing concrete insn format abstractions]?
Certainly, but there are so many fish to fry.