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] |
Hello all,
Trying to continue this topic after a while.
Doug Evans wrote:
Dmitry Eremin-Solenikov wrote:
Hello all,Hi. cgen currently doesn't handle instructions with opcode bits beyond
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?
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |