Re: [RFC] Add support for Renesas RX architecture

[Doug Evans <dje@google.com>]

On Mon, Dec 7, 2009 at 3:19 PM, DJ Delorie <dj@redhat.com> wrote:
>
>> Rather, it's that such support was always planned, it just needed
>> someone to add it.
>
> For the record, here's the limitations I've found...
>
> * The opcode descriptions are generated by exploding macros to get all
>  the prefix/operand byte permutations (about 12,000 total).  I.e. a
>  single variable-length opcode is converted into dozens of
>  fixed-length opcodes.  Regenerating takes about an hour, and
>  maintenance is a nightmare.

That was always just a temp hack until var-length support was complete.
[at which time, btw, cgen will no longer be responsible for 4MB source
files in opcodes :-)]

btw, for reference sake, some basic changes in cgen's data structures
brought the time down for m32c from 30mins to 5mins last time I
visited this.  It's still too long, and more can be done, but it was
easy to do.

> * cgen doesn't handle the opcode-vs-decodable bits in m32c very well.
>  The hash table has nothing left to work with (every bit is an
>  operand in *some* opcode), so the disassembler takes a noticably
>  long time starting up, especially given that the exploding macros
>  create many opcodes to hash.

I can't imagine there being anything inherent in cgen that prohibits a solution.
If a hash table isn't the best tool for a particular port, we can add
something that is.

> * The disassembler always reads MAX(opsize) bytes, so the .text
>  sections have to be padded with NOP bytes to prevent crashes.

Ditto.