This is the mail archive of the
cgen@sourceware.org
mailing list for the CGEN project.
Re: cgen -> opcodes problem
- From: Dmitry Eremin-Solenikov <dbaryshkov at gmail dot com>
- To: cgen at sources dot redhat dot com
- Date: Wed, 24 Feb 2010 14:41:08 +0000 (UTC)
- Subject: Re: cgen -> opcodes problem
- References: <20091227081006.GA23270@doriath.ww600.siemens.net> <4B39014D.4000203@sebabeach.org>
Hello all,
Trying to continue this topic after a while.
Doug Evans wrote:
> Dmitry Eremin-Solenikov wrote:
>> Hello all,
>>
>> I'm back to my m68hc08 binutils port done via cgen. Recently I've again
>> stumbled upon a problem with instructions, whose base? length != ISA
>> base length.
>>
>> E.g. in the attached stripped test case, the 'ttt' instruction either
>> (should be assembled as 0x9E 0xF1) is misencoded as 0xsmth 0x00. Is
>> this my fault? Or is this the expected behaviour and I should define
>> f-seccode in some other way?
>>
>> Could you please help me?
>>
>>
>>
> Hi. cgen currently doesn't handle instructions with opcode bits beyond
> the base insn size very well. I have a sandbox with this fixed, but
> it'll be awhile (month or more?) before it all gets checked in.
What is the current status of your sandbox? Do you have any patches available?
Or any intermediate work? Can I/we do something to help you to clean this up?
I'm currently trying to dig into ifmt-mask stuff, but it takes time...
> In the meantime, setting base-insn-bitsize to 16 may work. [It *should*
> work, but there may be attributes of your port I haven't taken into
> account.]
Setting base-insn-bitsize to 16 break disassembler: it starts looking for
16-bit masks instead of 8-bit for each and every instruction, and this doesn't
seem to work for lsb0 = #f port.
--
With best wishes
Dmitry