Re: cgen -> opcodes problem

[Doug Evans <dje@sebabeach.org>]

Dmitry Eremin-Solenikov wrote:
> 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.
>
>   

Hi.  It's very slow going, mostly because this isn't my day job.  Sigh.

It's easier to work with specific bugs though.  Can you send me your 
port to try?  Complete sources for building binutils would be best 
(either as a collection of patches or as a tarball I can ftp or some such).