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: Doug Evans <dje at sebabeach dot org>
- Cc: cgen at sources dot redhat dot com
- Date: Fri, 26 Feb 2010 14:39:22 +0300
- Subject: Re: cgen -> opcodes problem
- References: <20091227081006.GA23270@doriath.ww600.siemens.net> <4B39014D.4000203@sebabeach.org> <hm3dq4$prb$1@dough.gmane.org> <4B85589C.1030508@sebabeach.org>
On Wed, Feb 24, 2010 at 7:49 PM, Doug Evans <dje@sebabeach.org> wrote:
> 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).
The port is maintained as a git tree at
git://m68hc08-utils.git.sourceforge.net/gitroot/m68hc08-utils/m68hc08-utils
You can browse code at
http://m68hc08-utils.git.sourceforge.net/git/gitweb.cgi?p=m68hc08-utils/m68hc08-utils;a=summary
If you'd prefer I can create a simple (2-3 insns) cut of the port,
demonstrating the problem.
--
With best wishes
Dmitry