As Thomas K wrote:
does anybody know, what's happen, if a real controller get a invalid
opcode?
The Verilog source code might give some more insight. Unfortunately,
even to someone with access to that source code, it's probably going
to be a tedious job to find it out.
Even then, there are basically two options: if the source code makes
clear decisions (e.g. by means of a "default" statement, or by
explicitly coding that pattern), it can be said for sure. If the
source code simply omits some cases, the step where it is turned into
actual logic (the synthesization) can optimize unspecified cases,
yielding unpredictable behaviour (it could e.g. be different on an
ATmega16 from an ATmega8 even though both used the same source code).
However, the avrfreaks article I mentioned claims that early
descriptoins of the AVR instruction set used one "X" bit in the SBRS
instruction, thus leading to a clear decision towards decoding 0xFFFF
into that SBRS, provided all later implementations did not delete that
internally from the Verilog code.
However, unless someone has kept such an early document (I'm afraid I
didn't; the article mentioned a databook from 1997), this is hard to
tell nowadays.
For reference, here is the test program mentioned in that article:
-----------code--------------------------------------------
.include "m163def.inc"
rjmp reset ; jump over the next few lines
; PORTB will only output 0x0F if the mcu reaches this point
after_reset: ; flash location 0x0001
ldi r16, 0xFF
out DDRB, r16 ; set PORTB as output
ldi r16, 0x0F
out PORTB, r16 ; output 0x0F
rjmp PC ; loop forever
reset:
ldi r31, 0x80 ; // set bit 7 in r31
; now the mcu will start executing 0xFFFFs
; starting from address 0x0007
;
;nop
;
; uncommenting the NOP will cause the 0xFFFFs
; to start from 0x0008 and the mcu will never
; execute the PORTB code
-----------code--------------------------------------------
Depending on that NOP line, if 0xFFFF is decoded as SBRS r31,7, port B
will output 0x0F or not.
We might try this on as many AVRs as possible, including more exotic
ones.
Maybe: "--invalid-opcode=(ffnop|break|abort)"
ffnop - FF FF interpreted as NOP without any message (or SBRS r31,7)
break - behaviour like breakpoint with message
abort - (the default) abort simulation with a message
I could live with that. I think the latter cases could be combined:
if the simulator instance runs against a debugger, then break, if it
runs standalone, abort.