This is the mail archive of the
mailing list for the CGEN project.
Re: cgen/gas: some support for funny-endian instruction sets
- To: fche at redhat dot com (Frank Ch. Eigler)
- Subject: Re: cgen/gas: some support for funny-endian instruction sets
- From: Doug Evans <dje at transmeta dot com>
- Date: Mon, 9 Jul 2001 15:53:08 -0700 (PDT)
- Cc: cgen at sources dot redhat dot com, binutils at sources dot redhat dot com
- References: <20010709123942.Q3715@redhat.com><email@example.com><firstname.lastname@example.org>
Frank Ch. Eigler writes:
> 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.
One recognizes this going in. But in the context of word-bitsize
I can't quite get that anal over it. In the context of something more
complex I'd tend to agree.
> : 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).
Ah. Then I don't have a problem with the patch _providing_
word[-_]bitsize is renamed (say insn[-_]word[-_]bitsize).
> For example: word-bitsize=16, base-insn-size=32
> insn-word=0x76543210 -EB=>0x76 0x54 0x32 0x10 -EL=>0x54 0x76 0x10 0x32
> insn-word=0x3210 -EB=>0x32 0x10 -EL=>0x10 0x32
Why isn't base-insn-size 16?