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


On Sat, Mar 6, 2010 at 1:15 AM, Doug Evans <dje@sebabeach.org> wrote:
> Dmitry Eremin-Solenikov wrote:
>>
>> 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.
>>
>>
>
> Hi.
> I've got a toolchain built and can run the gas testsuite.
> Are these failures expected?
> [just want to establish a baseline]
>
> Running /misc/dje/gnu/m68hc08/myrepo/gas/testsuite/gas/m68k/all.exp ...

Hmmm. m68hc08 isn't an m68k-family device.

-- 
With best wishes
Dmitry


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