cgen -> opcodes problem

cgen -> opcodes problem

[Dmitry Eremin-Solenikov]

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

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?

-- 
With best wishes
Dmitry


[-- Attachment #2: m68hc08.cpu --]
[-- Type: text/plain, Size: 3126 bytes --]

; Freescale M68HC08/HCS08 opcode support, for GNU Binutils.  -*- Scheme -*-
;
; Copyright 2009 Free Software Foundation, Inc.
;
; This file is part of the GNU Binutils.
;
; This program is free software; you can redistribute it and/or modify
; it under the terms of the GNU General Public License as published by
; the Free Software Foundation; either version 3 of the License, or
; (at your option) any later version.
;
; This program is distributed in the hope that it will be useful,
; but WITHOUT ANY WARRANTY; without even the implied warranty of
; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
; GNU General Public License for more details.
;
; You should have received a copy of the GNU General Public License
; along with this program; if not, write to the Free Software
; Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston,
; MA 02110-1301, USA.

(include "simplify.inc")

(define-pmacro (dif x-name x-comment x-attrs x-word-offset x-word-length x-start x-length x-mode x-encode x-decode)
  (define-ifield
    (name x-name)
    (comment x-comment)
    (.splice attrs (.unsplice x-attrs))
    (word-offset x-word-offset)
    (word-length x-word-length)
    (start x-start)
    (length x-length)
    (mode x-mode)
    (.if (.equal? x-encode #f)
	    (encode #f)
	    (.splice encode (.unsplice x-encode)))
    (.if (.equal? x-decode #f)
	    (decode #f)
	    (.splice decode (.unsplice x-decode)))
    )
)

(define-pmacro (dnif x-name x-comment x-attrs x-word-offset x-word-length x-start x-length)
  (dif x-name x-comment x-attrs x-word-offset x-word-length x-start x-length
       UINT #f #f)
)

; define-arch must appear first

(define-arch
  (name m68hc08) ; name of cpu architecture
  (comment "M68HC08")
  (insn-lsb0? #f)
  (machs m68hc08)
  (isas m68hc08)
)

(define-isa
  (name m68hc08)
  (base-insn-bitsize 8)
  (default-insn-word-bitsize 8)
  (liw-insns 1)
  (parallel-insns 1)
)

; Cpu family definitions.
;
(define-cpu
  (name m68hc08bf)
  (endian big)
  (word-bitsize 8)
)

(define-mach
  (name m68hc08)
  (cpu m68hc08bf)
)

(define-model
  (name m68hc08)
  (comment "Generic M68HC08 model")
  (attrs)
  (mach m68hc08)
  (unit u-exec "Execution Unit" ()
	1 1 ; issue done
	() ; state
	() ; inputs
	() ; outputs
	() ; profile action (default)
	)
)

(define-hardware
  (name h-pc)
  (comment "M68HC08 program counter")
  (attrs PC)
  (type pc UHI)
)

(dsh h-a "Accumulator" () (register QI))

(dnif f-bitsel "bit for bit set/clear ops" () 0 8 4 3)
(dno bitsel "bit for bit set/clear ops" () h-uint f-bitsel)

(dnif f-opcode "first insn byte" () 0 8 0 8)

(define-pmacro (build-hex2 num) (.hex num 2))
(define-normal-insn-enum insn-opcode "insn opcode enums" () OP_ f-opcode
  (.map .upcase (.map build-hex2 (.iota 256)))
)


(dni nop
  "nop"
  ()
  "nop"
  (+ OP_9D)
  (nop)
  ()
)


;(dnif f-seccode "second insn byte" () 0 16 8 8)
(dnif f-seccode "second insn byte" () 8 8 0 8)
(define-normal-insn-enum p-insn-opcode "insn opcode enums" () SEC_ f-seccode
  (.map .upcase (.map build-hex2 (.iota 256)))
)

(dni ttt "ttt insn" ()
     "ttt"
     (+ OP_9E SEC_F1)
     (nop)
     ())

Re: cgen -> opcodes problem

[Doug Evans]

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.

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.]

Re: cgen -> opcodes problem

[Dmitry Eremin-Solenikov]

On Mon, Dec 28, 2009 at 10:04 PM, Doug Evans <dje@sebabeach.org> 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.

Can you share some preliminary patches?

> 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.]

Won't this break single-byte instructions?


-- 
With best wishes
Dmitry

Re: cgen -> opcodes problem

[Doug Evans]

Dmitry Eremin-Solenikov wrote:
> On Mon, Dec 28, 2009 at 10:04 PM, Doug Evans <dje@sebabeach.org> 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.
>>     
>
> Can you share some preliminary patches?
>   

The changes are non-trivial.  I'll see what I can do.
[e.g. maybe putting them on a branch]

>   
>> 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.]
>>     
>
> Won't this break single-byte instructions?
>
>   

cgen looks for insns shorter than the base-size (counter-intuitive, I 
know) and handles them accordingly.

Re: cgen -> opcodes problem

[Dmitry Eremin-Solenikov]

On Mon, Dec 28, 2009 at 10:04 PM, Doug Evans <dje@sebabeach.org> 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.
>
> 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.]

I haven't dig into that, but setting base-insn-bitsize to 16 broke
disassembler badly.


-- 
With best wishes
Dmitry

Re: cgen -> opcodes problem

[Dmitry Eremin-Solenikov]

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

Re: cgen -> opcodes problem

[Doug Evans]

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).

Re: cgen -> opcodes problem

[Dmitry Eremin-Solenikov]

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

Re: cgen -> opcodes problem

[Doug Evans]

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 ...
FAIL: cross-section branch
FAIL: PIC generation
FAIL: Incorrect Displacement too long error
FAIL: operands
FAIL: cas
FAIL: bitfield
FAIL: link
FAIL: fmoveml
FAIL: mcf-mov3q
FAIL: mcf-movsr
FAIL: mode5
FAIL: mcf-mac
FAIL: mcf-emac
FAIL: gas/m68k/mcf-coproc
FAIL: gas/m68k/mcf-fpu
FAIL: mcf-trap
FAIL: mcf-wdebug
FAIL: cpu32
FAIL: br-isaa.d
FAIL: br-isab.d
FAIL: br-isac.d
FAIL: ctrl-1.d
FAIL: ctrl-2.d
FAIL: 68000 operands

Re: cgen -> opcodes problem

[Dmitry Eremin-Solenikov]

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

Re: cgen -> opcodes problem

[Doug Evans]

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

Thanks.  I'll just ignore all of them then.