This is the mail archive of the cgen@sourceware.org mailing list for the CGEN project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cgen -> opcodes problem


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



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