Added Support for AVR Processor Atmega64M1

[Nickster44]

Hello,

My purpose for using Ghidra for the first time was to reverse engineer an AVR binary for the Atmega64M1. The generic AVR processor did not produce good assembly results so I made a PSPEC and LDEFS file to have support for the Atmega64M1.

I don't really want to set up the development environment, because I don't think I'll have any other contributions, and I don't use git very much.

Using these files though helped massively for my purpose, so I thought if anyone else needed automotive Atmel processor support I could share.

Thanks for this amazing program! Hopefully, I'll have another need for it in the future.
avr8_atmega64m1.zip

[Nickster44]

Oh, I would also like to add that I did notice some strange differences between the Ghidra ASM and the Atmel Studio debugger. For example, if the actual instruction was ROL (Rotate Left) R16. Ghidra would show ADD R16, R16. Multiply by 2 and adding the same thing to itself is the same I guess. I don't know if this is common for AVR disassembly, just based on how the opcodes are structured. But you end up with functionally identical results, but sometimes not using the mnemonically correct ASM opcode.

[GhidorahRex]

In this case, the instruction is not only equivalent, but rol is implemented by the processor as an alias to ADC. We don't always implement special cases of aliased instructions.

The AVR8 has several: bclr n, bset n, lsl, clr, tst, and rol in all these cases the behavior of the instruction is identical to the alias. With adc vs rol or add vs lsl it's difficult to know if the context of the instruction would make more sense as an add or shift. Whereas with eor rd, rd vsclr rd it's pretty obvious that it should zero out the register, so the clr mnemonic would be preferred.

[Nickster44]

Yes! I did notice some of those other examples as well. How does the Atmel Studio Debugger know the context? Does it just have more cases where it checks for redundant operations and chooses the more coherent ones, like clr rd instead of eor rd, rd? This is of course in the context where the debugger does not know the source code either and just pulls it from flash.

[GhidorahRex]

Neither the debugger nor Ghidra could know if the original instruction was adc r0, r0 or rol r0. The debugger is just checking if rd=rr in those cases and all cases of adc r0, r0 is represented as rol r0 regardless of which of the two was the original assembly instruction. We could do that, but I'm more concerned with how to represent the semantics of the instruction for decompilation. Usually the decompiler can simplify things like rd ^ rd => rd = 0, but for shifts and rotates that's more difficult to simplify.

[Nickster44]

Ahh okay. I wonder how many other instruction set designs do this as well. Very cool, thanks for your insight!

[GhidorahRex]

Quite a few. I know of some examples in ARM (push is an alias for stmdb sp!), MIPS (move is an alias for addu $r1, $r2, $zero), x86 (nop is an alias for xchg ax, ax - although it very quickly became a bona fide separate instruction). It's a very common mechanic