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


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


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