decode-bitsize (Was: Re: delayed branches and zero overhead loops)

[Joern Rennecke <joernr@arc.com>]

[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]

On Tue, Feb 13, 2007 at 04:11:52PM -0500, Frank Ch. Eigler wrote:
> The decoder generator is fully automatic.  If you represent decodable
> bits without cheating, it will do a reasonable job.

Actually, I realize now that I have a much bigger problem with the decoder
generator.
Originally, I set out to set default-insn-bitsize, base-insn-bitsize and
default-insn-word-bitsize all to 16, because that's what I should do according
to the documentation.  However, that gave me tons of ambiguity warnings.
from previous postings on the cgen mailing list and the xstormy port I've
gathered that I have to set base-insn-bitsize to 32.  Apart from the
ilink / noilink thing, that got rid of the spurious ambiguity warnings.
However, when compiling the decoder, I got tons of warnings about neative
shifts.  Declaring base-insn-bitsize as 32 does not make it so: it still
stays 16 once you have 16 bit instructions.
And the second level decoding tables are also generated using base-insn.
As bits from beyond the first 16 bits are needed, this results in a negative
shift.
I had though that I had solved this porblem by declaring bit fields in the
second word using a word offset, but i've found now that the effect is that
the decoder generator will completely mask out these bits from the insn -
even in the final comparisons against entire_insn to check if there is a
match.
It won't mask it out in the constant value to compare against, though,
so any insn that requires a bit in the second 16 bits to be set is decoded as
@CPU@_INSN_X_INVALID.

When I put the fields back to use no word offsets, the matching tests
are OK, but as the decoding switch statements also use bits from
beyond the first 16, they again end up with negative shifts.
I've tried hacking -gen-decoder-switch so that it always fetches the required
bits, but all I get is a re-fetch of the first 16 bits.
So, the decode-bitsize in the table-guts somehow is 16, even though that
is insufficient to cover all the included bits.

I have appended a copy of ARCompact.cpu version that get translated to a
decoder with negative shifts.

[-- Attachment #2: ARCompact.cpu.bz2 --]
[-- Type: application/x-bzip2, Size: 17542 bytes --]