This is the mail archive of the binutils@sources.redhat.com 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]

Re: cgen/gas: some support for funny-endian instruction sets



dje wrote:

:  > 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
buggy toolchain.


: 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.


- FChE


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